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Preface 


Honeywell Bull's Software Product Support Services for CP-6 large systems 
offers software support services through the Customer Services Division (CSD). 
They are available to all properly Licensed users of that software. This 
handbook describes these services and the procedures that users within the 
United States should follow to take advantage of them. For CP-6 systems 
outside the United States support policies vary; please contact your Honeywell 
Bull Marketing representative for the exact procedures to follow. 


CSD installs and services information systems hardware and software worldwide 
through its network of customer service engineers, technical and remote 
Support centers, National Response Center (NRC), service centers, and parts 
and repair depots. CSD employees serve in all 50 states, Puerto Rico, and 
many foreign Locations. The division is headquartered in Newton, 
Massachusetts. 


Computer Aided Publication (CAP) is an advanced electronic technical 
publishing system. CAP is based on the document database concept which also 
takes advantage of many features of the CP-6 Operating System. The Honeywell 
Bull CP-6 documentation group authors, edits, reviews, and creates Laser print 
masters with integrated text and graphics using CAP. This manual is a product 
of CAP. 


Readers of this document may report errors or Suggest changes through a STAR 
on the CP-6 STARLOG system. Prompt response is made to any STAR against a 
CP-6 manual, and changes will be incorporated into subsequent releases and/or 
revisions of the manuals. 


The information and specifications in this document are subject to change 
without notice. Consult your Honeywell Bull Marketing Representative for 
product or service availability. . 


Copyright (c) Honeywell Bull Inc., 1982, 1987 File No.: 1W13 
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About This Manual 


Section 1 of the handbook provides a very general overview of the CP-6 
Software Product Support Services that are available to Licensed users of CP-6 
systems. 


Section 2 describes the responsibilities that the users have so that optimal 
support can be provided. 


Section 3 outlines and describes the procedures to interface with the National 
Response Center (NRC) when placing requests for assistance. 


Section 4 describes the role of the CP-6 TAC. in the support process and how to 
utilize the services offered. 


Section 5 discusses in some detail the various components of the LADC support 
environment available to customers. 


Section 6 suggests guidelines for submitting problem reports to CP-6's on-Line 
technical problem reporting system, STARLOG. 


Section /¢” describes how to get started using the STARLOG database and 
commands. 


Appendix A describes the STARLOG data base. 
Appendix B describes STARLOG command syntax. 


Appendix C Lists the telephone numbers used in support of CP-6 sites. 


Related Manuals 


The following is the List of manuals supporting the CP-6 Operating System and 
associated software. 
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Manuals may be ordered from: 


Honeywell Bull Inc. Telephone: . 
National Distribution Operation Customers . (800) 343-6665 
47 Harvard Street Honeywell Bull (HVN) 392-5215 


Westwood, Massachusetts ~ 02090 


! = previous System Support manual (CE41) has been divided 
into a more manageable three volume set 


Notation Conventions 


The following table Lists and describes notation conventions used in this 
manual. 
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Notation Description 


Lowercase Letters 


Lowercase letters indicate that the element is a variable, to 
be replaced with the desired value. 


Capital Letters 


Capital letters indicate a Literal, to be entered as shown. 


Special Characters 


Special characters are literals, to be entered as shown. 


Numerals 


Numerals standing alone are Literals, to be entered as shown. 
Numerals embedded in or affixed to a string of capital letters 
are also Literals, to be entered as shown. Numerals embedded 
in or affixed to a string of Lowercase letters are part of the 
variable name to be replaced with a desired value, for example 
ae 


Brackets 


An element inside brackets is optional. For example, the 
notation 


H[ EIGHT J=vaLlue 


means that the bracketed portion may be omitted, or truncated 
at any point. 
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Notation Description 


Braces 
Elements inside a pair of braces identify a required choice. 
{ONIOVERI TO} 


means that either a value of ON, OVER or TO must be entered. 


The OR bar separates elements in a List from which one element 
may be, or must be, chosen. 


{213} 


means that either the number 2 or 3 must be entered. 


Horizontal ELLipsis 


The horizontal ellipsis indicates that a previous bracketed 
element may be repeated, or that elements have been omitted. 


fid1 [, tid2,...] 


means that one or more name values may be entered, with commas 
inserted between the name values. 
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Section 1 


Overview of CP-6 Support 


The primary objective of Honeywell Bull's Support Services is to help its CP-6 
customers achieve the highest possible availability from their systems. These 
services cover the system hardware, the operating system software, CP-6, and 
all associated supported application software packages. Honeywell Bull feels 
that the key to effective support is in making a problem visible to the 
appropriate personnel in a timely manner. 


Honeywell Bull's approach to achieving this goal is to provide customers with 
a single focal point for all calls for assistance. This point of contact is 
called the Honeywell Bull National Response Center (NRC), Located in Atlanta, 
Georgia. 


Note: For CP-6 systems installed outside the United States, support policies 
vary; please consult your Honeywell Butl Marketing representative for details. 


The CP-6 support environment is unique in that it provides an alternative 
vehicle for requesting highly responsive software assistance via an 
interactive technical problem reporting system called STARLOG. STARLOG and 
other extremely useful automated support facilities are available to customers 
through the Los Angeles Development Center's support computer. 


National Response Center 


The NRC can coordinate and dispatch rapid and efficient support, 24 hours a 
day, 7 days a week. When a call for assistance is placed via the toll-free 
telephone number, the caller is questioned by the call coordinator as to the 
nature of the call. If the nature of the problem is hardware, then a Customer 
Service Specialist will be quickly dispatched to the customer site. If the 
call is for a software problem and is placed between the hours 08:00 a.m. and 
06:00 p.m. in the customer's time zone, then the call will be switched to the 
CP-6 Technical Assistance Center (TAC) in Phoenix. The handling of calls 
placed outside these normal working hours is dependent upon the severity of 
the problem. If the problem is neither a system down nor one that is 
preventing essential production from completing (see Section 3, Calling the 
NRC), then the call will be transferred to the CP-6 TAC and processing will be 
delayed until the next working day. When a critical software problem does 
exist outside normal working hours, every effort will be made to respond to 
the call. However, it should be noted that the CP-6 TAC is not staffed during 
these hours and immediate response cannot be guaranteed. 
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The NRC administers and tracks calls for assistance for all Honeywell Bull 
products. Information about all calls is entered into an on-line 
administrative data base that contains the following: 


o Hardware and software configuration for the system where the probLem 
occurred 


fe) Hardware maintenance and software support contractual information 
o Service history for each system 
© Contact sequence to be used to respond to a call for assistance. 


ALL calls entered into the data base are monitored to completion. 


Technical Assistance Center 


The CP-6 TAC is the focal point which receives and responds to all calls for 
software technical assistance. The TAC is staffed by hardware and software 
specialists who are highly trained to remotely diagnose and analyze problems. 
They are equipped with terminals, complete current documentation and access to 
data bases containing the Latest information on the status of any known 
technical problem. These specialists will work with the customer or on-site 
Customer Service Specialist, at their request, to resolve both hardware and 
software difficulties. 


When the NRC relays a request for assistance to the TAC, it is assigned to a 
Specialist, who calls either the customer's primary technical contact or the 
Customer Service Specialist for the site, depending on who placed the call, to 
discuss and attempt to resolve the problem. Problem resolution may entail one 
or more of several actions by the Specialist: 


o Providing a recovery/avoidance procedure as a temporary correction of a 
problem 


Oo Answering a simple question 

o Providing a patch to correct a software problem 

fe) Requiring that the Specialist remotely access the customer's system to 
analyze the problem symptoms in an effort to diagnose and isolate the 


difficulty 


o Forwarding the request to another organization within Honeywell Bull for 
follow-up action (e.g., Marketing or Local CSD Hardware Support). 
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Los Angeles Development Center 


The Los Angeles Development Center (LADC), the organization directly 
responsible for the production of CP-6, is an integral part of the total CP-6 
support environment. 


The CP-6 support computer system resides at and is operated and managed by 
LADC. The objectives of this system are 


1. To provide a highly automated central support process 


2. To permit the CP-6 customers, the CP-6 TAC, CP-6 CSD Field Software 
Support, LADC and other interested parties to communicate in a highly 
visible manner on issues relating to support. 


3. To provide the customers with maintenance updates to the CP-6 operating 
system and related processors by means of incremental patch files that may 
be synchronously transmitted to their sites (or made available on magnetic 
tape). 


Numerous support tools, procedures and data bases facilitate an extremely 
efficient support process. At the center of the whole process is CP-6's 
on-Line technical problem reporting system, STARLOG. The LADC support 
environment is the subject of Section 5. 
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Section 2 


User Responsibilities 


In order for the NRC and the TAC to provide optimal software product support 
services, the customer's full cooperation is required in a number of areas, 
including: 


1. Designating one or more software knowledgeable individuals to serve as the 
customer's primary technical contact for all software product problems 
(see "Primary Technical Contact"). 


2. Installing the most recent release of the software product. 


3. Performing those problem definition activities and remedial actions 
prescribed by the TAC and/or LADC (see "Problem Definition and 
Documentation"). 


4. Installing patches to the operating system and associated processors as 
they're released (see "System Maintenance"). 


5. Permitting reasonable privileged access to your system by the TAC and/or 
LADC for purposes of problem duplication or analysis (see "System 
Access"). 


6. Ensuring that your own system's personnel have received adequate CP-6 
training so to be able to effectively administer the system. 


Primary Technical Contact 


Each customer should designate the name of an individual, typically the site's 
System manager, who will serve as the primary contact for the TAC for all 
matters relating to software support. The designation is made via the initial 
NRC sign-up forms made available during the initial system installation. The 
individual should be sufficiently knowledgeable to relate technical aspects of 
a reported software problem to the TAC's technical representative and to apply 
any remedial instructions that are suggested. 


RESPONSIBILITIES 
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Should it be necessary or desirable for a different person at the site to 
receive the TAC call in response to a given support request, that person's 
name and complete telephone number must be specified during the initial 
service request to the NRC. When the caller specifies no telephone number, 
return calls by the TAC will normally be made to the telephone at the 
customer's system console. 


It is strongly suggested that the system manager (or site's technical contact) 
perform the following activities routinely: 


fo) Enter all the site's software problems into LADC's problem data base, 
STARLOG. Then monitor the status of the site's problem reports in case 
additional information is needed. Section 7 illustrates how to monitor a 
site's outstanding problem reports. 


fe) Examine software dump files that are created automatically, retaining 
files that represent actual problems and deleting dumps that do not 
represent actual problems. Section 6 discusses retention of dumps and 
other files in the :SYSTAC account. 


o Review ELAN's Summary (SUM) report and the Anticipatory Maintenance 
Summary (AMS) report daily and periodically review trends apparent in 
those reports with the CSD Field Engineer. 


Problem Definition and Documentation 


In general, before requesting software support services, the site's technical 
contact should collect all applicable documentation that will be useful in 
discussing the problem with the TAC Specialist. Generally, the following is 
considered the minimum documentation that should always be available when a 
call is placed: 


1. A concise statement of the external symptoms of the problem 


2. Error log data, console history log and dumps created as a result of the 
problem 


3. If known, the data necessary to duplicate the problem 


4. The patch level the system is currently running and the software product 
version (which for a processor may differ from the operating system 
version). 


Beyond this basic minimum, the subsequent investigation may require the use of 
various other files depending on the nature of the difficulty including source 
files, data files, dumps and XEQ files. 
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System Maintenance 


Obviously, a good deal of time could be wasted by the TAC and LADC working on 
a problem that has already been fixed by a patch that has been released but 
not installed at a site reporting the problem. As a result, it is recommended 
that sites not run their systems at a patch Level more than 4 weeks behind 
that which is current. Section 5 discusses the procedure to obtain and 
install patches. 


Patch Files 


Under normal conditions, each week LADC will create an incremental patch file 
that contains all. the host, FEP and processor patches. For the current 
release, those patches have been successfully exposed to general testing on 
the LADC CP-6 support computer and, consequently, are deemed ready to be 
released to customers. The CP-6 Support Group places that file into an 
account (.ZZZPATCH) on the CP-6 support computer which is accessible to all 
customers. The format of the file name for this incremental patch file is 

> VVVPATCH_INCRyww where vvv is the version number of the CP-6 system for which 
the patches are intended and yww is the last number of the year followed by 
the week number. For example, the file :DOOPATCH_INCR705 is the incremental 
patch file for DOO CP-6 that was released in week 5 of 1987. For all 
customers that have synchronous communications capability the file will 
automatically be transmitted to the account .:SYSTAC which must exist at each 
site with a password known to LADC. For those that do not have this 
Capability, arrangements can be made so that the incremental patch files are 
sent to the site on tape. 


Note that the files sent to the customer sites are not transmitted until a 
site actually establishes the synchronous connection to the support computer 
(see section 5). Consequently, so that excessive file space is not wasted on 
the support system, customers are requested to periodically pick up these 
files. — 


Full patch decks are maintained in the same account, ZZZPATCH, for each week 
an incremental is released. The format for the name of the full patch decks 
is :vvvPATCH_RELyww where vvv and yww are as defined above for the incremental 
files. 
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PMERGE.X 


Installation of these incremental patch files at the customer site is 
accompLished via the PMERGE.X processor. The processor is used to merge the 
additional patches into the file at the site that contains the full set of 
patches currently in use. A complete description of the processor may be 
obtained using the CP-6 HELP facility on the customer system. 


System Access 


The support philosophy of CP-6 requires that LADC and the TAC be able to logon 
to the customer system and use CP-6 standard supplied tools to perform problem 
analysis with the aim of providing a timely resolution. More specifically, 
support personnel expect to be able to logon to a customer system with the 
Logon :SYSTAC,LADC with the privileges that the account is created with BY 
DEFAULT (this is done automatically when the system is initially installed). 
These privileges permit one to access any file, run the host and FEP analysis 
programs, snap running memory in the host or FEP and other high-privileged 
processes. Denying CP-6 support personnel access to the customer system 
through anything but a fully privileged account will in many cases extend the 
resolution time of problems reported through the NRC and/or STARLOG. The 
customer will be required to supply, in Lieu of privileged system access, 
complete supporting problem documentation transmitted to the CP-6 support 
computer or sent via the U.S. mail or other non-electronic means. Meanwhile, 
problem analysis will be put on hold (in STARLOG that means a STAR's status is 
changed to DOCUM) pending receipt of adequate documentation. 


Following installation of the CP-6 software, the customer should password 
protect the :SYSTAC,LADC account with a password and inform the CP-6 TAC 
through the NRC. Any subsequent change of the password by the customer 
warrants a call to the TAC. 


The LADC automated support process is very dependent upon the existence of a 
synchronous communications path between each customer site and the support 
computer. Its use is varied and extremely important to an efficient support 
process. Some of the more common usages are: 


1. Retrieval of testcases from the customer system for supporting 
documentation for software problem reports. 


2. Convenient means for customers to retrieve temporary patches for software 
problems or other important files related to support. 


3. Convenient means for customers to keep abreast of support activity on the 


software problem reports they've made through STARLOG. 
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4. Receiving incremental patch files queued for transmission to customer 
sites automatically on a weekly basis by the LADC support process. 


5. Gathering of stability information from each of the sites on a periodic 
basis as a means of identifying potential trouble sites. 


It is the customer's responsibility to ensure that the synchronous facility is 
installed and operational (see Section 5) and that the CP-6 TAC is informed of 
the details. 


Without these accesses to the customer site, the CP-6 support process is 
severely hampered. A customer wishing to run a totally secure system would 
have to make other arrangements for shipping problem documentation to the TAC 
and/or LADC as well as receiving the periodic incremental patch files. 
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Section 3 


Calling the NRC 


The procedure for placing a call for software assistance, either with a 
difficulty or a usage question, is simple and straightforward. The call 
procedure and key guidelines are outlined below. Adherence to these 
procedures should greatly enhance the overall quality and timeliness of the 
resulting software product support service. 


Prerequisites 


The following tasks should be performed prior to placing a call for assistance 
with a software difficulty: 


1. If possible, determine the repeatability of the difficulty. 
2. If possible, isolate the difficulty to a small testcase. 


3. Have the necessary documentation available so that attempts at problem 
duplication and/or analysis can proceed without delay. 


4. Assign a technical individual to follow through with the investigation of 
the difficulty in cooperation with the TAC Specialist who responds to the 
call for assistance (see "Primary Technical Contact” in Section 2). 


The following tasks should be performed prior to placing a call requesting 
information relating to the usage of some system facility or program product: 


1. Prepare specific questions in terms of the desired result you are 
attempting to achieve by using a given software facility. 


2. Make use of and refer to available software documentation. 
3. Assign a technically knowledgeable individual, if other than the primary 


technical contact, to discuss the question when the TAC Specialist 
responds to the request for technical assistance. 
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Call Dialogue 


Any call for software assistance is initiated through the NRC. The toll-free 
telephone numbers are 


(800) 282-4350 for calls within Georgia 
and 
(800) 241-1634 for calls within any other state. 


The NRC operator answering your call will proceed through an established 
dialogue designed to determine who you are, what system you are running, the 
severity and a brief description of the difficulty you're experiencing. It is 
extremely important that the guidelines discussed here are exactly followed so 
that unnecessary delays do not result from miscommunication between the 
nontechnically oriented NRC operator and yourself. The dialogue follows: 


1. The NRC operator will initiate the call with a greeting that should 
include his or her name. For future reference if problems should occur 
with the handling of the call, you should write down the name of the 
operator. 


2. The NRC operator will ask "What is your site identification number?". If 
this number is not known, your Customer Service Account Representative 
(CSAR) or local Customer Services Division (CSD) Representative should be 
contacted. 


3. The NRC operator will verify the company name and address and ask whether 
you are running CP-6. It is important at this point to ensure that the 
operator understands that your site is running CP-6 since you may be taken 
through a dialogue that's unrelated to CP-6 and most surely will result in 
undue delays in the processing of your assistance request. Consequently, 
stop the dialogue at this point when CP-6 is not mentioned with a 
statement that you're a CP-6 customer. 


4. The NRC operator will ask "What is the customer contact's name and 
telephone number?" to ensure that the call is returned to the proper area 
code, telephone number and technical contact. 


5. "Does the difficulty involve Hardware, Software or is it Unknown?" is then 
asked. It is recommended that you respond either Hardware or Software at 
this point. 
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The NRC operator will ask "Is the entire system down?" and then "Is the 
problem preventing essential production from completing?". The answers to 
these questions should simply be either YES or NO. Do NOT attempt to 
explain the situation that exists at your site. The following criteria 
should be used for determining your answers to these key questions: 


YES indicates a critical situation that includes either of the following: 
a) System inoperative, cannot boot, system hung, etc.,... 


b) System interruptions occur to the extent that daily production is 
impossible or severely hampered. 


c) Major production application is inoperative (e.g., Transaction 
Processing (TP) is down, payroll cannot be run, etc.,...). 


NO indicates a noncritical situation. This classification includes 
requests for information or questions related to situations that do not 
fall into the critical criteria categories as defined above and other 
irritants that the customer can usually work around. 


Procedures have been established to ensure rapid handling of a software 
problem of a critical nature (i.e., one that is blocking a production 
run). The action taken in these cases depends solely on your assessment 
of the situation. When these calls are received in the TAC, every effort 
is made to respond to them immediately. Judicious use of the critical 
call category will in the long run be of benefit to you and other 
customers when such assistance is required. 


The NRC operator will ask "For what product code are you reporting the 
difficulty?". Your response should be 


OSS for problems that relate to the CP-6 host operating system software or 
host processors. If you have any doubt, this is the code you should 


supply. 
CSS for problems that relate to FEP or communications software. 


You will be asked "What is the software problem?". Your response should 
be brief (about 25 characters) and to the point. Do not attempt to enter 
into a technical discussion of the problem. 


The NRC operator will then terminate the call and provide you with a 
reference number of the form '"999999AA" which should be written down. If 
at any time during the subsequent problem investigation you find it 
necessary to contact the TAC Specialist assigned to the call, then it is 


‘possible for you to call the TAC directly via a toll-free number. The TAC 
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operator will ask you for your reference number and then determine whether 
the TAC Specialist you are attempting to contact has an open call for your 
site that corresponds to this number. If so, you will be connected with 
the TAC Specialist. If not, you will be directed to initiate an 
assistance request through the NRC. 


Response Time 


When a call or service request is received in the TAC, the call is placed in a 
queue accessible to all the CP-6 TAC Specialists. The Specialist who is 
assigned to the call will contact the individual. specified in step 4 above. 
This return call should normally be expected within one hour of the customer's 
call for assistance to the NRC. 


Calls classified as critical will receive the fastest response from the TAC. 
Response time will vary with the availability of the specific resource needed 
at the time the call is received. Every effort is made to return critical 
calls within 15 minutes. 
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Section 4 


TAC Objectives 


The tasks normally performed by the CP-6 TAC Specialist responding to a 
request for software assistance are as follows: 


1. Obtain a clear and concise definition of the problem 
2. Isolate the difficulty to a particular unit of software 


3. Accumulate or put together the documentation necessary to completely 
define the problem and, if necessary, to duplicate it 


4. Provide a work-around for the problem or, if available, a temporary patch 
to fix the problem 


5. If necessary, take action to involve other organizations (e.g., Marketing, 
CSD Hardware Support, etc.,...) to assume responsibility for problem 
resolution. 


Problem Definition, I|solation and Documentation 


The first task performed by the TAC Specialist when responding to a customer 
request for software assistance is to obtain a clear definition of the 
difficulty being encountered. Obviously, this task is greatly simplified by 
the customer who has properly prepared for the. call by knowing exactly where 
the problem exists and having accumulated the necessary documentation that 
describes it and, in some cases, to duplicate it. 


For many calls, the TAC Specialist may already have experienced the problem 
being described since the TAC is a focal point for problems being exper ienced 
by the CP-6 customer base and reviews daily all in-coming software technical 
problem reports entered into STARLOG. Consequently, due to the broad exposure 
to existing CP-6 problems, the request for assistance is often satisfied 
during this first call-back. 
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Having defined the problem, it may be necessary for the TAC Specialist to - 
Logon to the customer system for further problem analysis in order to isolate 
the difficulty to (1) CP-6 supported software, (2) customer developed 
software, (3) misuse of supported software or (4) failing hardware. However, 
prior to doing so, the Specialist will often query the other Specialists in 
the TAC as to whether they have encountered any similar problem and, if not, 
query the software problem data base using STARLOG to determine whether 
another customer has reported a similar problem. 


If no known existing problem matches what the customer is reporting, the 
problem analysis on the customer system may require the Specialist to utilize 
various CP-6 diagnostic tools including DELTA, ANLZ, ELAN, REPLAY, STATS as 
well as some of the other CP-6 utilities and processors. If necessary, the 
documentation accumulated in this phase of the analysis should be moved to the 
LADC support computer. The documentation or testcase can be moved by using 
HASP synchronous file transfer or by using a PC communicating via TYMNET. The 
technique used depends on the size of the files and the type of problem 
reported. 


Avoidance Techniques 


Throughout the problem definition phase, foremost in the Specialist's mind is 
the task of finding a solution to the customer's problem. Often that solution 
may be provided best by means of a work-around procedure that involves the 
customer altering operational procedures or recoding a portion of a program in 
order to avoid the reported difficulty. At other times a temporary patch may 
be developed to correct the difficulty that can be provided to the customer by 
means of a PC or synchronous file transfer. 


Reassignment of Problem Responsibility 


The final solution for any software problem that's found to exist with the 
CP-6 system or related supported processor Lies with the producer, LADC. 
Consequently, for such difficulties handled by the TAC, a STAR will be 
generated as part of the call handling procedures, if one does not already 
exist. After submitting the STAR, a developer will be assigned responsibility 
and the STAR will be opened. Any documentation gathered by the Specialist 
during problem analysis will be made available to the developer. For all but 
the most critical of problems, the system down call, the follow-up 
responsibility of monitoring the STAR for further documentation requests, and 
its resolution Lies with the customer originating the call. 


In some cases, it may be determined during analysis that the problem is not a 
software problem at all but a hardware problem. When this happens the TAC 
Specialist will take steps to transfer the call responsibility to the Hardware 
TAC. The Hardware TAC Specialist will review the findings with the Software 
TAC Specialist and if agreement is reached that a hardware problem exists, the 
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Hardware TAC will initiate contact with the local Customer Service Account 
Representative (CSAR) to discuss the problem and recommend corrective action. 
The Software TAC Specialist will, of course, inform you of the findings, 
course of action and then, close the software request for assistance. The 
final responsibility for any repair action on the customer system hardware 
Lies solely with the local CSD Hardware Support organization. 


In other cases, the reported difficulty may be determined to be neither 
software nor hardware. It's possible that it may be a problem that may best 
be handled by the Marketing Representative for the customer site. Or, it may 
be a problem with Software Distribution. The TAC Specialist will, for any 
problem that's the responsibility of any organization within Honeywell Bull, 
initiate the steps necessary to inform that organization of the problem that 
exists. 


For those problems for which the cause is determined to be the customer's own 
software or that of another vendor, the Specialist will request that the 
customer assume responsibility for initiating corrective action. 
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Section 5 


LADC Support Environment 


CP-6 software support and maintenance can be viewed as a continuously flowing 
process with each new customer problem starting a sequence of steps to analyze 
and solve it. Although many times the sequence is quite short, there are 
instances when the problem is subtle and complex and, consequently, involves 
numerous interactions between the customer, the TAC, the CSD Field Software 
Support Specialist and LADC. With hundreds of these interactions underway at 
any given time, tracking and controlling the situation calls for a high degree 
of automation. The CP-6 automated support process which is based on the LADC 
support computer utilizes a Large number of software tools, procedures and 
data bases which all CP-6 customers are asked to use in order to meet their 
responsibilities in the support process. 


Communications Environment 


The communications environment on the LADC support computer is depicted in 
Figure 5-1. Both asynchronous and synchronous communication paths are 
available to customers as well as support personnel attempting to assist them 
when problems arise. 
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Figure 5-1. LADC Communications Environment 


ASYNC Capabilities 


Customers are able to log on to the LADC support computer as time-sharing 
users by dialing up the system and entering an account, account name 
combination of the form: 


ZZZCUST ,900s ite-id,password 


where site-id is the system identifier associated with the customer system and 
password is the password for the account, account name combination. Note that 
the password for the customer logon is initially supplied to new customers on 
the packing slip accompanying the first shipment of CP-6 software. The 
customer is free to change the password upon Logging on to the system. 


Access to the system may be accomplished via a direct connection using a Los 
Angeles phone number or through a local TYMNET number. The numbers available 
for direct connection are: 
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300/1200 baud (4 Lines) 
- or - 
300/1200 baud (8 Lines) 


(PLease consult your Honeywell Bull Marketing 
Representative for these telephone numbers. ) 


The toll-free number for TYMNET customer support is (800) 336-0149. Customers 
should contact this organization to obtain the Local TYMNET number for their 
area and to report any difficulties experienced with the service provided. 


To access the LADC support system through TYMNET the following steps are 
necessary: 


1. Establish connection with the TYMNET system by dialing your Local TYMNET 
number . 


2. Upon connection, reply "A" (for most terminal types) to the prompt "please - 
enter your terminal identifier". No carriage return is necessary. 


3. Type a control-H character to set TYMNET up for full duplex operation. 


4. In response to "please Log in:", enter 


(Please consult your Honeywell Bull Marketing 
Representative for this logon string.) 


followed by a carriage return. Note that the '";"' separates the TYMNET 
Logon account from the TYMNET password. If only the TYMNET Logon account 
is entered, then the TYMNET system will prompt for the password with 
“password:". If this occurs then the password should be entered. 
Finally, if a wrong password is entered, the customer will be prompted 
again for the correct password with "error, type password:".. 


5. Upon successful completion of the above Logon sequence and connection to 
the LADC support computer, TYMNET will output “host : call connected" and 
the LADC system will prompt you with the standard CP-6 Logon. 


Once Logged on to the LADC support system, the customers will have access to 
only those processors that are necessary to accomplish their support 
responsibilities. The processors available, each of which will be discussed 
briefly Later in this section, are WOODPECKER, DABBLE.X, EDIT, MAIL, BEAM, 
STARLOG, and ARCHLOG.STAR. a 
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WOODPECKER 


It's often necessary for customers to determine whether there is any output in 
the queue on the LADC support computer awaiting synchronous transmission to 
their site. The WOODPECKER processor is available for purposes of displaying 
all output destined for a particular workstation. The format of the command 
entered at the IBEX level is 


'WOODPECKER 


DABBLE . X 


A bulletin board facility is available on the LADC support system for 
customers that permits the reading of messages or comments in any of a number 
of discussion areas called meetings. Users are able to join the conversation 
in any of a selected number of the meetings. Some of the meetings available 
to customers include a generalized discussion meeting (BB), a discussion of 
some techniques for using 6EDIT (6EDIT_NOTES) and a discussion of various CP-6 
System management techniques (TECHNIQUES). A List of all existing meetings 
may be obtained with the DABBLE command CATALOG. For additional information 
and assistance with DABBLE.X, use the CP-6 HELP facility. 


EDIT 


Full access to the CP-6 EDIT processor is allowed for all customers. Refer to 
the CP-6 Programmer Reference (CE40) or use the CP-6 HELP facility for 
additional information or assistance. 


MAIL 


Full access to the CP-6 MAIL processor is allowed for all customers. Refer to 
the CP-6 Introduction to MAIL (HAO3), the CP-6 MAIL Reference (HA04), or use 
the CP-6 HELP facility for additional information or assistance. 


It is strongly recommended that all customers use the MAIL facility on a 
regular basis, i.e., put an invocation of the MAIL processor in their setup 
file on the LADC support computer in order to List any new messages they may 
have received. Frequently, valuable support information (e.g., ALERTs 
referencing bad patches) are electronically MAILed to customers. 


Note: MATL is NOT to be used for reporting or solving problems. For problem 
reporting nd analysis always use STARLOG, so that your findings will be 
visible to all CP-6 users. 
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BEAM 


Customers will find it useful to use the BEAM processor on both their own 
systems as well as the LADC support computer. It is the means by which files 
are transported between CP-6 systems. The syntax of the command entered at 
the IBEX Level is 


‘BEAM source-fid { OVER | ON | INTO } destination-fid dwsn 


where source-fid identifies the file which is intended to be transmitted, 
destination-fid specifies the name to give the file once it is transmitted to 
the destination site and wsn is the workstation name of the destination site. 


The BEAM processor will respond with 


. BEAMing source-fid 
Enter account,name to run dwsn CR for JIT account ,name 
* 


After entering the account,name combination in which a job will be transmitted 
to and run at the destination site to create the file being sent, the BEAM 
processor will request 


Please enter your password dwsn (echo is off) 
ie 


For additional information or assistance, use the CP-6 HELP facility for BEAM 
in the X account, i.e., HELP (BEAM.X). Note that the X account is an account 
suppLied with the CP-6 system that contains numerous tools. See the CP-6 X 
Account Pocket Guide (HA16) for more information. 


Occasionally your site may want to obtain a file from the support computer. 
In that case the tool MAEB must be in the X account, and the account under 
which your job runs must be allowed write access to your site's :SYSTAC 
account. The following command executed at your site causes the BEAM job to 
be scheduled at the next synchronous connection to the support computer. 


'XMIT beam_jcl_fid to JE@LADC 
where beam_jcl_fid refers to a file such as the following: 


' JOB 

TRES” -aitieews 

'BEAM fid OVER file.:SYSTAC dwsn 
2SYSTAC ,LADC 

password 
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where 


wsn 


is your site's workstation name. 


password is the password for your site's :SYSTAC account. 


SYNC Capabilities 


The synchronous communication paths available are used by customers, the TAC 
and LADC. To utilize this facility there are a number of requirements and 
steps that the customer must follow: 


5-6 


One of the FEPs at the customer site must have the synchronous 
communication hardware installed. 


A 2400 baud modem must be available at the customer site. 

The customer must agree upon a 1-to-8 character mnemonic by which their 
site will be referred to by all support personnel and automated processes 
that run on the LADC support system. This name is known as the customer's 
workstation name (WSN) and must be communicated to Pave via the TAC when 
the system is initially installed. 


The customer must execute the file SYNCLADC.SUPPORT that's provided on the 
CP-6 software release tape as follows: 


'XEQ SYNCLADC.SUPPORT XXX=mysite 
where mysite is the agreed upon WSN. 


The customer must install the BISYNC FEP software in the FEP that contains 
the synchronous hardware. 


The customer must configure the synchronous channel that is connected to 


the 2400 baud modem as follows using the NETCON processor: 


'NETCON 

*SEL NODE=fep-node 

xCONFIG .xxxx HARDWIRE=NO,SPEED=2400,LOGON='‘LADC' 
KKILL .xxxx 

*ENABLE .xxxx 

*END 


where fep-node is the FEP node number of the FEP that contains the FEP 
Synchronous hardware and xxxx is the synchronous channel number. 
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Once this is done, the Line will remain dedicated to use by LADC until 
overridden with a new CONFIG command. NETCON remembers all configurations 
in the file :NETCON.:SYS. The customer may, however, wish to establish 
permanent configurations in a file that is XEQ'ed after a system startup. 


If all of the above steps have been satisfied, synchronous transmission of 
jobs and/or files between the customer site and LADC is possible. Synchronous 
transmission may be initiated by the customer by dialing the toll-free number 


in California 
or 
in states other than California. 


(Please consult your Honeywell Bull Marketing 
Representative for these telephone numbers. ) 


Connection will automatically take place between LADC and the customer system 
and any files queued at LADC for the customer site or queued at the customer 
site for LADC will be automatically transmitted. 


The BEAM processor may be used to transmit files to/from LADC. 


Automated Support System 


The objective of the LADC automated support system is simply to keep the 
software support and maintenance process flowing as efficiently as possible 
from the time a software problem (STAR) is reported via STARLOG through the 
time the problem is fixed by delivery of a patch to the customer site and/or 
the CP-6 source code is updated for the next release. There are not only 
numerous complex interactions between those submitting STARs and the various 
support personnel but, also, many internal processes that have to be managed, 
monitored and accounted for. Figure 5-2 illustrates the process. 
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Figure 5-2. CP-6 Automated Support Process 
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STARLOG 


STARLOG is an interactive on-line information management system used by CP-6 
customers and support personnel with access to the LADC support computer to 
report product problems and documentation errors. The system enables a rapid, 
highly visible information flow that can involve a substantial interaction 
among the problem submitter, the TAC, the software developers at LADC, users 
at other sites and CSD field support personnel. Any problem that will require 
a software change to the CP-6 operating system or any related processor must 
be peperted via STARLOG. 


Problems reported cheough STARLOG are called System Technical Action Requests 
or STARS. Once a STAR is submitted, a dialogue is started between the 
customer and appropriate support organizations within Honeywell Bull. Most of 
this dialogue is visible to all customers, making the STARLOG data base a 
generally available and useful “known problems" data base. Customers who wish 
to take advantage of this facility are able to monitor STARs submitted and 
responses provided throughout the entire CP-6 customer base on a daily basis. 


The reporting sequence starts with a customer submitting a STAR. The 
correction process may involve several CP-6 support organizations including 
the CP-6 TAC, LADC, CSD Field Software Support, the Software Distribution 
Center or possibly Marketing. Subsequent dialogue is conducted and recorded 
by appending NOTEs to the STAR. NOTES are used by both the customer and CP-6 
Support personnel to add additional information, identify avoidance procedures 
and document the resolution of the problem. STARs are resolved and closed 
with information, a patch or a source fix targeted for a future release of the 
software. The type of solution depends on the severity and type of problem. 
Some STARS are resolved by a combination of information on how to avoid the 
problem, a patch for the current version of the software and/or a permanent 
source fix for the next release. : 


The STARLOG information system uses an IDS-II data base called STARBASE. Each 
STAR is a record in the data base and each NOTE is a subrecord in a STAR. 


STARLOG has a HELP facility associated with it that provides users with syntax 
formats, parameter descriptions, examples and concepts at their terminals 
while in a STARLOG session. 
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To initiate a STARLOG session after logging on to the LADC support computer 
simply enter: 


'STARLOG 
and you will be greeted with, for example, 


STARLOG BO2B 09:45:03 FRI MAR 20 '87 


# 


Customers are referred to Section 6 of this handbook which discusses 
recommended guidelines for submitting STARS of various types. Section 7 
describes common STARLOG usages and techniques. In addition, this handbook 
provides in Appendix A, STARBASE information and characteristics, and in 
Appendix B, a summary of all STARLOG commands. Portions of this manual 
comprise the STARLOG CP-6 HELP facility. 


As always, if further information is required the CP-6 TAC may be contacted. 


TATTLE 


STARLOG provides a journal of the sequence of interactions on all problems 
submitted, but to keep the support process flowing efficiently it is useful to 
notify the programmers in a more visible way when certain events occur. This 
is done automatically with a program called TATTLE, a multi-purpose message 
processing tool. TATTLE, responding to signals from several sources, writes 
notes in STARLOG and sends electronic MAIL to the appropriate programmers. 
Some specific instances are: 


O Notification that a testcase requested from a customer site in a STAR has 
arrived at the LADC support computer. For this to function properly, 
testcases must be sent to the account .ZZZTEST and each filename must 
begin with the number of the STAR for which the documentation is intended. 


fe) Notification that a patch for a STAR has completed the test cycle and is 
now generally available to customers in an incremental patch file. 


o Notification that a bad patch has been detected which requires corrective 
action. 
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STARGAZE 


One of the initial steps in processing a newly received STAR is to assign it 
to the programmer responsible. With the Large number of STARLOG problem 
categories called SUBJECTs (see Appendix A) and the Large number of developers 
in LADC and Phoenix the task could be tedious and time consuming. However, 
the STARGAZE process accomplishes this automatically through a periodically 
invoked JCL stream that interrogates STARLOG for newly arriving STARs. It 
then assigns the appropriate programmer names to the new STARS based on a 
table which correlates STAR subject names with the module owner. The process 
is driven via a CP-6 processor called GOOSE which starts the sequence every 15 
minutes. 


For all severity 1 STARS submitted, STARGAZE will also write a MAIL message to 
the responsible programmer, the CP-6 TAC and the LADC Support Group notifying 

all automatically that a severe problem has been reported that requires their 

attention. 


Starlord STAR Review 


STARLOG permits users to be defined with varying degrees of privileges which, 
among other things, authorizes the level of administrative capability granted. 
Users with the highest administrative privilege are known as Starlords. When 
a user creates a new STAR or appends a NOTE to an existing star, that 
information is not generally visible to other customers until the information 
supplied has been "reviewed" by a Starlord. This is done primarily to protect 
the customers from misinformation and to make sure information that could 
compromise the security of their systems is not carelessly made visible to the 
outside world. It should be noted that this review process does not 
needlessly slow the problem solving process since the CP-6 TAC and the 
developers at LADC are able to view any STAR or note the moment it is 
submitted. The tasks performed by Starlords during this review process 
include: 


1. For each new STAR submitted determine the correctness of the subject 
category used by the submitter on the basis of the STAR description 


2. For each new STAR and every new NOTE 


fe) Ensure no information that compromises the customer's security exists 
(e.g., account names, passwords, etc., ...) and edit, if necessary. 


fe) Ensure that no information exists that could be misinterpreted or used 
to the detriment of a customer's system. 
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3. Change the status of a STAR according to the information supplied. For 
example, if more information is requested from the customer by the 
assigned programmer, then the status of the STAR will be changed from OPEN 
to DOCUM and remain in that status until the information requested is 
supplied. 


4. When a STAR is first submitted determine whether the STAR is a duplicate 
of a previously submitted STAR. 


The CP-6 TAC currently performs the Starlord review process at Least twice 
each day. | 


ARCHLOG .STAR 


With each release of CP-6, the STARLOG data base, STARBASE, is purged of old 
STARS (i.e., those closed by the release of the new software) and archived to 
another data base, the ARCHLOG data base.. This process provides a valuable 
source of past history of all problems reported by CP-6 customers. It is 
accessible by atl customers by using the ARCHLOG.STAR processor. The 
ARCHLOG.STAR processor is essentially another version of STARLOG that permits 
users to perform STAR displays or STAR searches based on varying criteria. No 
STAR updating is permitted. The following is necessary to invoke the 
processor: 


!ORES MEM=256 
'ARCHLOG.STAR 
# 


Analyst Alert Stars 


An Analyst Alert STAR is one way the CP-6 TAC and LADC communicate 
extraordinary problems or concerns. This is a STAR which has a severity of 
"A". It is recommended that customers regularly generate a List of ALL such 
STARS for reference. 


Support Processes 

In addition to the processes already discussed relating to the STARLOG 
processor, there are a number of others that are of interest and are important 
for an overall understanding of the automated support process in use at LADC. 
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Diagnostic Data Col lection 


For each CP-6 system, the account :SYSTAC on the system pack is created to 
receive various files that can aid in problem analysis and resolution. The 
pertinent files are Listed below by the file name pref ix: 


: DF -~ Dump Files. The ANLZ processor is the tool provided to obtain 
essential information from dump files. The full file name is of 
the form :DFvvvxnnn, where vvv is the operating system version 
(e.g., DOO), x is the tape boot sequence number that is 
incremented at each tape boot, nnn is the numeric dump 
identifier. See Section 6 for more information. 


=:ERRLOG - Error Log files. The ELAN processor is the tool provided to 
obtain meaningful reports from error log files. The full file 
name is of the form :ERRLOGyymmdd, where yymmdd represents a 
date. 


:OCHIST - Operator Console History files. The REPLAY processor is the 
tool provided to obtain information from these files. The full 
file name is of the form :OCHISTyymmdd, where yymmdd represents 
a date. 


Early Warning System 


The frequency and nature of system interruptions at a customer site is useful 
information in the support context. The pattern and trend at a given site, 
and comparisons to other sites, can give insight into problem situations and 
alert us to changes in site status. This data is recorded automatically by 
the ELAN error logging processor which runs continuously at each customer 
site. The data is transmitted to the LADC support computer on a regular basis 
where it 1S organized into a history file by the EARLY WARNING program. We 
then operate on that file to produce reports about the stability of customer 
Systems. The sequence is started by the customer synchronously Logging on to 
the support computer to obtain the current incremental patch update. While 
the patches are being transmitted, the error log data is passed to the support 
computer and, subsequently, processed without human intervention. 
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Remote Debugging 


In the process of analyzing a customer-reported software problem, it is often 
necessary for the CP-6 TAC or the assigned programmer to log on to the 
customer system. With many programmers at LADC and Phoenix and with the 
increasing number of sites throughout the world, each with different access 
parameters, getting logged on could be a time consuming task. 


The processor RING solves this problem with an automatic dial-out capability 
accessible from the LADC support computer. It interfaces with programmable 
dial-out modems and uses a data base containing the access data. The LADC 
programmers need only to tell RING the customer site name (WSN) for which 
access is desired and, shortly, they will be Logged on to that computer from 
the terminal in their office without having to know phone number, Logon or 
password. They can examine a dump file or interact with the failing program 
to experience the problem symptoms directly. 


A very useful extension of this technique is provided by another CP-6 facility 
called DRIBBLE which permits the CP-6 TAC or LADC programmer to capture on the 
support computer an on-Line session on the customer system. This could be 
used to transfer small testcases or to make a hard-copy of a formatted summary 
of a crash dump using ANLZ without ever moving the dump file from the customer 
computer or having to find a hard-copy terminal. 


Patch Management 


The process of patching a problem reported in STARLOG and getting that patch 
delivered and installed on the customer system involves a number of operations 
at LADC as well as some that must be performed on the customer system by the 
customer. 


1. The process starts when a STAR is closed by a developer with mention that 
a patch will be submitted. ALL severity 1 and 2 STARs will be closed with 
a patch, if possible. The status of the STAR will be made TPATCH while 
the patch proceeds through the various stages of testing. 


2. The responsible programmer uses standard tools to format and create the 
patch and performs initial testing to determine that the patch solves the 
specific problem reported by the STAR. If necessary, a dedicated CP-6 
system will be used. 


3. Each week the LADC Test Group merges all new patches into the current 
patch deck and attempts a trial boot and regression testing. The patches 
for the current release go through at least one week of exposure on the 
LADC support computer before being generally released to customers. 
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Each week the LADC Test Group moves all tested and ready to be released 
new patches into a file called the incremental patch file. The format for 
the name of these incremental files in :vvvPATCH_INCRyww where vvv is the 
CP-6 system version number (e.g., DOO) and yww is the fiscal week number 
in which the patch will be released. These files are accessible to 
customers and are available in the account .ZZZPATCH. 


At this time a full patch deck is created by the LADC Test Group by using 
the PMERGE processor to incorporate the new incremental patch file. The 
name of the full patch decks are of the form z:vvvPATCH_RELyww and, again, 
they are accessible and available to customers in the account .ZZZPATCH. 


Each week on Thursday the LADC Test Group queues the incremental patch 
file for the week for synchronous transmission to all customer sites that 
have synchronous communications capability. 


The customer initiates the incremental patch file transmission by 
establishing the synchronous communication Link to LADC. 


The customer uses the PMERGE facility to incorporate new patches into the 
customer patch file and then places the new patch file on tape. See the 
CP-6 System Manager Handbook (CE60), System Creation, which illustrates 
this process. Typically the new patch file, with site-specific TIGR 
commands merged in, is copied to a scratch tape to be used as the second 
patch tape. 


The patches are installed the next time the customer performs a tape boot. 
The operator responds "Y'" to "Change boot options” in order to be prompted 
for information that allows reading of the second patch tape, and responds 
"X'' to "Tape 1 patches" and "MTRPB" to "Tape 2 patches". Refer to the 
System Start-up and Recovery section of the CP-6 Operations Reference 
(CE34) for further information. 


Any time during the patch test cycle the customer may request a pre-release 
copy of the patch due to the severity of the problem reported. This may be 
done via a call to the NRC or by appending a note to the appropriate STAR. 
The customer, however, should be aware that the patch so delivered has not 
undergone full testing and is provided on a use-at-your-own-risk basis. 
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PATCH_HIST 


A complete history of the events pertaining to the release of patches is 
maintained in reverse chronological order in a customer accessible file called 
PATCH_HIST in the account .ZZZPATCH. Each time an incremental file is 
generally delivered to the CP-6 customer base an entry is made. Also, 
warnings concerning the release of bad patches and other patch related 
information is frequently input to the file. It is recommended that all 
customers regularly examine the contents of the file. 


MAIL ALERTs 


A parallel, more visible means of bringing to the attention of customers 
problems or information that relates to the CP-6 patch process is the MAIL 
ALERT system. Each time a patch that has been generally released is found and 
verified to be bad to the extent that it may jeopardize normal customer 
operation, an ALERT is MAILed to all customers. It is highly recommended that 
all customers regularly use the CP-6 LADC support computer MAIL processor. 
Customers should definitely check for ALERTs prior to installing any new 
incremental patch files. 
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Section 6 


STAR Guidelines 


Preceding sections of this handbook focus on problem reporting procedures to 
be followed by customers who have just installed a new CP-6 system. Over time 
as the system manager gains experience with the CP-6 system, software 
reporting procedures can become more streamlined. 


Although hardware problems must always be reported to the NRC, software 
problems need not be. In fact, the experienced customer may accumulate the 
necessary supporting documentation, log on to the support computer and build a 
STAR directly. This section describes guidelines for STAR content and 
appropriate supporting documentation for various types of software problems. 
This section also briefly discusses dump analysis and retention of dump and 
other files which are automatically created by the CP-6 system. 


STAR Format and Content 


The resolution time for any STAR submitted obviously depends on many factors, 
some directly under the control of the submitter. A STAR properly submitted 
will generally significantly reduce the time necessary to arrive at a 
solution. The ideal situation is to submit a STAR and have the first note 
added be one that compliments you on its quality and provides you with the 
solution to your problem. The following should always be considered when 
entering a STAR: 


1. Choose a TITLE that briefly describes the problem using as many keywords 
as possible. 


Obviously, a proper TITLE is not going to reduce a STAR's resolution time. 
However, since the STARLOG data base serves as a repository of known 
problems and the best method of determining whether one's problem has 
already been reported and/or fixed is via a STAR search looking for 
keywords in the TITLE, it will be of benefit for others encountering the 
same problem by providing a handle by which the problem report can easily 
be Located. 


2. Use your name when submitting a STAR or appending a NOTE. 


Don't use generic names Like the company name for which you work or the 
WSN that's associated with your site. Doing so makes it difficult for the 
TAC or other support personnel to telephone you during the problem solving 
process and introduces unnecessary delays. 
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3. Enter a clear, concise and accurate problem description. 


Confine each STAR to a single problem. Supply a complete description of 
the symptoms surrounding the difficulty. Suggest what you believe may be 
Causing the problem. Describe any new, unusual, or different 
circumstances that may be related to the difficulty. Try to anticipate 
the questions the person responsible for solving the problem will ask; 
that is, ask yourself what information you would need to solve the 
problem. 


4. Provide adequate problem documentation. 


Adequate documentation, of course, is highly dependent on the type of 
problem being reported. Generally speaking, though, it's desirable to 
supply enough information so that the problem may be duplicated on the 
customer system and/or the LADC support computer. That may be difficult 
for some types of problems, but for most compiler, application or data 
base problems it's nearly essential. 


For system host or FEP screeches and for host single user aborts or snaps, 
it's usually sufficient to identify the product version, current patch 
level of your system, and dump(s) that were created on your system. 
However, the process is speeded if, for such problems, you send 
preliminary information extracted from the dump(s) in question to LADC as 
supporting documentation for the STAR. See Section 7, "Sending Supporting 
Documentation" which describes ways to send (BEAM or transmit) this 
information to the CP-6 support computer. 


Diagnostic Tools 


In addition to the standard CP-6 diagnostic tools (e.g., ANLZ, ELAN, STATS, 
etc.) that are available and described in the CP-6 System Support Reference 
(HA2Z0, HA21, HA22), there are a number of tools available in the X account 
that are of some use and will be briefly described here. Additional 
information for each may be obtained using the CP-6 HELP facility. 


ELBBIRD.X 


The ELBBIRD processor (DRIBBLE spelled backwards) should be used on every 
DRIBBLE file that you intend to BEAM to LADC as supporting documentation for a 
STAR. It produces a VFC-less file that makes it generally more readable. The 
following is necessary to clean-up a DRIBBLE file: 


'ELBBIRD.X dribble-file-fid 
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SNAP.X 


On occasion it will be necessary to produce a snapshot dump of a running user 
that is causing some difficulty (e.g., see the section on 'TP Problems'). The 
SNAP.X facility meets these needs. It may be invoked as follows: 


'SNAP.X .user# 


where user# is the user number of the user to be dumped. 


Optimal Problem Reporting 


The following subsections will identify the most desirable elements required 
to quickly resolve the difficulty for the type of problem being reported. For 
each problem type, a TITLE is suggested, useful information to be included in 
the description is identified, and supporting documentation requirements are 
outlined. 


Dumps 


Dumps are created by the CP-6 system in the :SYSTAC account on the system 
packset (DP#SYS). Dump file names are of the form :DFvvvxddd, where vvv is 
the operating system version (e.g., C01, DOO, etc.) and xddd identifies the 
specific dump file. 


The starting point in analyzing a dump is the recovery screech code, which is 
of the form mid-code-sev where 


mid identifies the monitor routine that initiated the particular screech 
process. 


code is a unique decimal number that identifies the failure. 


sev is the severity of the failure (determines what classification of dump 
is produced), as follows: 


- Full host system screech 
Single user abort (SUA) 
~ Snapshot dump (snap) 

- FEP screech 


WUON 
I 


The CP-6 processor that is used to provide much of the problem documentation 
for problems associated with system dumps resulting from screeches, SUAS and 
snaps 1s called ANLZ. Its use is described in the CP-6 System Support 
Reference, Volume 1 (HA20). 
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In the examples that follow, reference will be made at times to the safe store 
frame that gets output as a result of the ANLZ REC command (see Figure 6-1) 
when analyzing host dumps. The information presented describes the monitor 
environment at the time the screech occurred. In particular, the contents of 
pointer register 2, $PR2, and the instruction counter, IC, will be referenced. 


'ANLZ 
ANLZ CO1 L66A (node OQ) 
Selected L66A -ANLZ D024 
:DFCO1D024 for UDE-M00501-6 at 22:19 FEB 11 ‘87 on LADC L66A 


Nodes: L66A 
L66A (node 0) Selected 
L66A -REC 

SCREECH CODE: 


UDE-M00501-6 $$ Memory fault 


CURRENT USER .122 ON LOGICAL PROCESSOR #0 AT 22:19:39 FEB 11 '87 


SAFE STORE FRAME: 
WORD 1 EVEN INSTR. opp INSTR. TIME STAMP 
775710777773 000306043776 200006756100 000001336007 010131 324665514411 
IC=FMD$TRNC+. 33 IR=. 104210 MRT=NO SSF=NO FLTCODE=1 
CP=0 SCR=0 ISSID=.6000 DSAR=.000000 EWSQ=8 VA=.35742-0 


ISR: .200000-0,BD=.777777-3,WSR=0,FL=.757,TY=0 
ASR: .33610-0,BD=.0-0,WSR=7,FL=.741,TY=1 

LSR: .32000-0,BD=.441-3 ,WSR=0,FL=.543,TY=1 
PSR: .33600-0,BD=.7-3 ,WSR=7,FL=.743,TY=1 


~ PRO: .1046-0-0,$LS3 DRO: .136000-0,BD=.33777-3 ,WSR=7 ,FL=.743,TY=0 
PR1: .466-0-0,$LS3 DR1: .136000-0,BD=.33777-3 ,WSR=7 ,FL=.743,TY=0 
PR2: .710-0-0,$LS16 DR2: .26366-0,BD=.3411-3,WSR=7,FL=.743,TY=0 
PR3: .62260-0-0,5LS83 DR3: .1420000-0,BD=.177777-3,WSR=0,FL=.703,TY=0 
PR4: .651-0-0,$LS16 DR4: .26366-0,BD=.3411-3,WSR=7,FL=.743,TY=0 
PR5: .652-0-0,$LS16 DR5: .26366+0,BD=.3411-3,WSR=7,FL=.743,TY=0 
PR6: .376-0-0,$LS16 DR6: .26366-0,BD=.3411-3 ,WSR=7,FL=.743,TY=0 
PR7: .25247-0-0,$LS2 DR7: .40000-0,BD=.75777-3,WSR=7,FL=.703,TY=0 


Figure 6-1. ANLZ REC Display (cont. next page) 
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000004 547104 777067 000020 000002 000000 000002 704177 


X12 MMJSFBTOIOP+.34 
X2: ITBSBEGIN+.57561 
X7: XSASMON+. 13 


A: 000000000005 Q@: 055055055055 E: 000 TIMER: 000133270000 


MORE STUFF FROM THE RECOVERY BUFFER: 


SSR: .32620-0,BD=.757-3 ,WSR=/,FL=.743,TY=1 
PSR: .33600-0,BD=.0-0,WSR=7,FL=.741,TY=1 
ASR: .33610-0,BD=.0-0,WSR=7 ,FL=.741,TY=1 
WSRs: .1,.1,.0,.14,.4,.5,.6,.10 

CURRENT COMGROUP: .0-0-0,$PSO 


Figure 6-1. ANLZ REC Display 


The following discussion will at times reference the IC and $PR2 from the safe 
store frame as output by the ANLZ TCB command (see Figure 6-2). Note that the 
TCB display in this case shows two safe store frames. The first, the ALTRET 
frame, describes the user's environment at the time of the last monitor 
service for which an abnormal condition was reported. The second and 
subsequent frames, EXCEPTIONAL condition frames, describe other abnormal 
conditions that the user has encountered (e.g., MSERR, M$XXX, faults). 


'ANLZ 
ANLZ C01 
L66A (node 0) Selected 
L66A -ANLZ FOQO6 
=DFCO1FO06 for ZIM-000775-5 at 19:21 FEB 26 '87 on LADC L66A 


Nodes: L66A 

L66A (node 0) Selected 
L66A -TCB (ASL) 

SYSID = 13359 :SYSTAC,LADC 


Figure 6-2. ANLZ TCB Display (cont. next page) 
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ALTRET FRAME: 

EVEN INSTR. ODD INSTR. TIME STAMP 
000000000143 Q00000000000 000000000000 Od00000000000 010154 075251137670 
1C=.071447 IR=.404010 MRT=NO SSF=NO FLTCODE=0 
CP=0 SCR=3 ISSID=.6000 DSAR=.000000 EWSQ=0 VA=.0-0 


ISR: .66000-0,BD=.107777-3 ,WSR=6,FL=.553,TY=0 
ASR: .33612-0,BD=.0-0,WSR=7,FL=.741,TY=1 

LSR: .32220-0,BD=. 107-3 ,WSR=7,FL=.543,TY=1 
PSR: .33600-0,BD=.11-3,WSR=7,FL=.743,TY=1 


PRO: .6006-0-0,$LS5 DRO: .1424000-0,BD=.105777-3 ,WSR=7,FL=.743,TY=0 
PR1: .6006-0-0,$LS5 DR1: .1424000-0 ,BD=.105777-3 ,WSR=7,FL=.743,TY=0 
PR2: .14-0-0,$LS4 DR2: .1420446-0,BD=.2377-3 ,WSR=7 ,FL=.743,TY=0 
PR3: .570-0-0,$LS7 DR3: .1540000-0,BD=.2333-3 ,WSR=7 ,FL=.743,TY=0 
PR4: .34-0-0,$LS6 DR4: .1532000-0,BD=.5777-3 ,WSR=7 ,FL=.563,TY=0 
PR5: .0-0-0,$L$5 DR5: .1424000-0,BD=.105777-3 ,WSR=7,FL=.743,TY=0 
.0-0-0,$LS6 DR6: .1532000-0,BD=.5777-3,WSR=7 ,FL=.563,TY=0 
.0-0-0,$LS7 DR7: .1540000-0 ,BD=.2333-3 ,WSR=7 ,FL=.743,TY=0 


000010 000034 001235 001713 000034 000035 001713 004007 


A: 000000000003 Q: 000000000000 E: 000 TIMER: 000024676000 


FMG-MOQ0083-2 Service request interrupted by break or control-y 


000100 000000040003 000000000035 061507401232 OQ00000000000 
EXCEPTIONAL CONDITION FRAME AT .110: 
EVEN INSTR. ODD INSTR. TIME STAMP 
000000000003 000000000000 000000000000 Od00000000000 010154 075251160342 
IC=.072502 IR=. 104010 MRT=NO SSF=NO FLTCODE=0 


CP=0 SCR=3 ISSID=.6000 DSAR=.000000 EWSQ=0 VA=.0-0 


Figure 6-2. ANLZ TCB Display (cont. next page) 


STAR GUIDELINES 
6-6 CE61-01 


ISR: .66000-0,BD=.107777-3,WSR=6 ,FL=.553,TY=0 
ASR: .33612-0,BD=.0-0,WSR=7,FL=.741,TY=1 

LSR: .32220-0,BD=.107-3,WSR=7,FL=.543,TY=1 
PSR: .33600-0,BD=. 11-3 ,WSR=7,FL=.743,TY=1 


PRO: .0-0-0,$LS5 DRO: .1424000-0,BD=.105777-3,WSR=7 ,FL=.743,TY=0 
PR1: .71762-0-0,$LS0 DR1: .66000-0,BD=.107777-3 ,WSR=6 ,FL=.553,TY=0 
PR2: .14-0-0,$LS4 DR2: .1420446-0,BD=.2377-3 ,WSR=7,FL=.743,TY=0 
PR3: .0-0-0,$LS5 DR3: .1424000-0,BD=.105777-3 ,WSR=7 ,FL=.743,TY=0 
PR4: .34-0-0,$LS6 DR4: .1532000-0,BD=.5777-3,WSR=7 ,FL=.563,TY=0 
PR5: .0-0-0,$LS5 DR5: .1424000-0,BD=.105777-3,WSR=7 ,FL=.743,TY=0 
.0-0-0,$LS6 DR6: .1532000-0,BD=.5777-3,WSR=7 ,FL=.563,TY=0 
.0-0-0,$LS7 DR7: .1540000-0 ,BD=.2333-3,WSR=7 ,FL=.743,TY=0 


000035 071756 071452 001713 000034 000035 001713 004007 
A: 000000303423 Q@: 000000303423 E: 000 TIMER: 000012410000 


JSE-MO00260-4 MSERR issued by Alternate Shared Library. 


000100 400000000000 001000000000 122305404044 000000000000 


Figure 6-2. ANLZ TCB Display 


The patchweek under which a dump occurred is important information that should 
be supplied when creating STARS. The patch file in use at the time the dump 
occurred is represented as x in the dump file name (:DFvvvxddd); x is the same 
as the Last letter in the patch file name (:PFvvvx) and is the tape boot 
sequence number for your site. 


To determine if a dump you are examining occurred under the current system 
patches, enter 


‘OUTPUT $VERSION 
The resulting display is the portion of the patch file fid that follows :PF. 
For example, if the current patch file is :PFDOOd, the display is DOQd. 
Compare the x in :PFvvvx and :DFvvvxddd. If they are the same, then the dump 
file is from the currently installed patch week, which may be displayed by 
enter ing: 
For the host: 


'WHAT.X PA 
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For the FEP: 


'DELTA 
>ANLZ FEP n 
>DUA G_PATCHWEEK, 2 


Host System Screeches, SUAs and Snaps 


There is a wide variety of full system screeches, SUAS and snaps that may 
occur and, as a result, a tailor-made procedure to identify all the 
information required to arrive at a solution is impractical. However, the 
information identified below will, in most cases, permit a fairly good 
preliminary analysis of the problem. 


SUGGESTED STAR TITLE: <wsn> scode @ ic 


where 
wsn is the site's workstation name. 


scode is the screech code in the form mid-code-sev (e.g., UDE-501-6) 
and 


ic is the instruction counter from the REC display (e.g., 
FMDSTRUNC+.33). 


STAR DESCRIPTION RECOMMENDATIONS: 


1. Give the name of the dump file on your system and the patch Level 
run at your site. 


2. Note any extraordinary events associated with the Screech, SUA or 


snap, including any suspicious errorlog entries or system console 
messages prior to the problem. 


3. If an SUA or snap is being reported, identify, when possible, the 
process the user involved was attempting to perform. The user can 
be identified from the dump using the ANLZ "SPY CUN" command. 


SUPPORTING DOCUMENTATION: 


BEAM the following ANLZ information extracted from the dump file: 
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REC "Dump recovery buffer 


7M $I "Display current instruction 

AUTO $LS16 FOR CUN WAPL "If $PR2 in the REC SSF, references $LS16 
AUTO $LS33 WAPL "If $PR2 in the REC SSF, references $LS33 
JIT CUN "Display minimal user information 

STAR "Obtain information appropriate to the 


"type of dump file. 


Host System Hang 


Your operational procedures to handle a host system hang should include steps 
to gather the necessary information to adequately document the problem in 
STARLOG prior to initiating an operator recovery. Also, note that the 
preferred method for initiating an operator recovery for a host system hang is 
through an execute fault (see CP-6 Operations Reference, CE34). 


SUGGESTED STAR TITLE: <wsn> Host System Hang a ic 


where 


wsn is the site's workstation name. 


is the instruction counter from the REC display. 


STAR DESCRIPTION RECOMMENDATIONS: 


1a 


Zs 


CE61-01 


Give the name of the dump file on your system and the patch Level 
run at your site. 


Indicate if all users are hung, one user is hung, or some users are 
hung. 


Note the response that on-Line terminal users received from an <ESC 
Q> while the system was hung. If some on-line users are hung and 
others are not, provide the <ESC Q> information for both types of 
users. . 


Were keyins possible at the system console? If so, describe the 
response to the PEND keyin. If the hang occurred during a ZAP, 
describe the response to the ZAP!! keyin. If the hang occurred 
during a boot, describe the type of boot performed, how far the boot 
proceeded in terms of the system console output and the response, if 
any, to the STARTUP!! keyin. 


Note any extraordinary events associated with the hang. 
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SUPPORTING DOCUMENTATION: 


Beam the following ANLZ information from the dump: 


REC "Output the recovery buffer 

USRT "Format the user table 

EVB "Format the event buffer 
{DS Snaps 


An IDS snap, identified by the screech code ZIM-775-5, occurs when the IDS 
alternate shared Library detects an abnormal condition. The dump that gets 
created documents the abnormal IDS environment and the user's environment that 
induced the condition. However, the dump alone generally is not sufficient 
documentation to resolve the difficulty. 


SUGGESTED STAR TITLE: <wsn> ZIM-775-5 ec @ ic 
where 
wsn is the site's workstation name. 


ec is the error code from the appropriate frame from the ANLZ command 
"TCB (ASL) CUN". 


ic is the instruction counter from that frame. 


Note that the "TCB (ASL) CUN" command will, in this case, output an 
ALTRET frame and one or more EXCEPTIONAL CONDITION frames. ANLZ will 
for each frame interpret the error code that caused it. 


In some cases, the ALTRET frame will document a condition and the first 
and only EXCEPTIONAL CONDITION frame will be an MSERR by IDS as a result 
of that condition. In this case, use the ALTRET frame when deciding the 
content of the title. | 


In other cases, when more than one EXCEPTIONAL CONDITION frame exists, 
the ALTRET frame will be of Little consequence and the first EXCEPTIONAL 
_ CONDITION frame should be used when writing the title. 
STAR DESCRIPTION RECOMMENDATIONS: 


1. Give the name of the dump file on your system and the patch Level 
run at your site. 
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2. Describe the external conditions exhibited by the user who induced 
the snap. For example, if the user was a terminal user, descr ibe 
the error messages displayed at the terminal. Note the user can be 
determined from the dump via the ANLZ "SPY CUN" command. 


3. Identify the files on your system that contain the DDL source for 
the schema, subschema and DMCL that define the IDS data base. Also 
identify of the source of the program causing the IDS abort. 


4. Provide the identity of an XEQ file on your system that may be used 
to duplicate the snap on your system. Also, any information 
required as input to the failing program should be provided. 


5. Describe the sequence of IDS calls that cause the failure. If 
possible, identify the Line number in the source of the program of 
the IDS call that causes the problem. 


SUPPORTING DOCUMENTATION: 
BEAM the information extracted from the dump file by ANLZ's command: 


STAR “Obtain information appropriate to the 
“type of dump file. 


A concise, readily transportable testcase that can be used to 
demonstrate the difficulty on the LADC support computer, if available 
will, generally, greatly reduce the time required for problem 
resolution. Note that for problems of this nature it's often necessary 
to duplicate the difficulty on the support system. Consequently, it may 
be necessary to transport Larger testcases on magnetic tape. It is also 
possible for support personnel to debug large testcases on your system, 
if you are prepared to help set up the environment. 


IBEX Snaps 
An IBEX snap is identified by the screech code CPC-/700-5 indicating that the 
CP-6 command processor, IBEX, has encountered an abort condition. The dump 
file created documents the environment of the user using IBEX at the time of 
the failure. 
SUGGESTED STAR TITLE: <wsn> CPC-700-5 @ ic 
where 

wsn is the site's workstation name. 

ic is the instruction counter from the EXCEPTIONAL CONDITION frame 

that results from the ANLZ "TCB (ICP) CUN" command. 
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STAR DESCRIPTION RECOMMENDATIONS: 


1. Give the name of the dump file on your system and the patch level 
run at your site. 


2. If possible, describe the process the user who caused the snap was 
attempting. Note that the identity of this user may be obtained by 
ANLZing the dump and entering the command "SPY CUN". 


Contact the user as soon as possible after the snap so that the 
details of what happened aren't obscured by the passage of time. 


SUPPORTING DOCUMENTATION: 


BEAM the information extracted from the dump file by ANLZ's command: 


STAR “Obtain information appropriate to the 
“type of dump file. 
DUA $LS10 FOR CUN,ICP “Display GETCMD context drea 
ARES Snaps 


An ARES snap, identified by the screech code ZJE-786-5, occurs when the ARES 
alternate shared Library detects an abnormal condition. The dump that gets 
created documents the abnormal ARES environment and the user's environment 
that induced the condition. However, the dump alone generally is not 
sufficient documentation to resolve the difficulty. 


SUGGESTED STAR TITLE: <wsn> ZJE-786-5 ec @ ic 
where 
wsn is the site's workstation name. 


ec is the error code from the appropriate frame from the ANLZ command 
"TCB (ASL) CUN". 


ic is the instruction counter from that frame. 


Note that the "TCB (ASL) CUN'' command will, in this case, output an 
ALTRET frame and one or more EXCEPTIONAL CONDITION frames. ANLZ will 
for each frame interpret the error code that caused it. 


In some cases, the ALTRET frame will document a condition and the first 
and only EXCEPTIONAL CONDITION frame will be an MSERR by ARES as a 
result of that condition. In this case, use the ALTRET frame when 
deciding the content of the title. 


STAR GUIDELINES 
6-12 CE61-01 


In other cases, when more than one EXCEPTIONAL CONDITION frame exists, 
the ALTRET frame will be of Little consequence and the first EXCEPTIONAL 
CONDITION frame should be used when writing the title. 


STAR DESCRIPTION RECOMMENDATIONS: 


1. Give the name of the dump file on your system and the patch Level 
run at your site. 


2. Describe the external conditions exhibited by the user who induced 
the snap. For example, if the user was a terminal user, describe 
the error messages displayed at the terminal. Note the user can be 
determined from the dump via the ANLZ "SPY CUN" command. 


3. Identify the file on your system that contains the DDL source for 
the data base causing the difficulty. Describe the DML commands 
that were used to cause the snap. 


4. Provide the identity of an XEQ file on your system that may be used 
to duplicate the snap on your system. ALso, any information 
required as input to the failing program should be provided. 


5. If a program is involved, describe the sequence of DML calls that 
Causes the failure. Identify the source of the program on your 
system and, if possible, identify the Line number in the source of 
the DML call that causes the probLem. 


SUPPORTING DOCUMENTATION: 
BEAM the information extracted from the dump file by ANLZ's command: 


STAR "Obtain information appropriate to the 
“type of dump file. 


A concise, readily transportable testcase that can be used to 
demonstrate the difficulty on the LADC support computer, if available 
will, generally, greatly reduce the time required for problem 
resolution. Note that for problems of this nature it's often necessary 
to duplicate the difficulty on the support system. Consequently, it may 
be necessary to transport larger testcases on magnetic tape. It is also 
possible for support personnel to debug Large testcases on your system, 
if you are prepared to help set up the environment. 
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DELTA Snaps 


A DELTA snap is identified by the screech codes DUX-xxx-5 indicating that the 
CP-6 debug processor, DELTA, has encountered an abort condition. The dump 
file created documents the DELTA user's environment and DELTA's environment at 


the 


time of the failure. 
SUGGESTED STAR TITLE: <wsn> DUX-xxx-5 @ ic 


where 
wsn is the site's workstation name. 


ic is the instruction counter from the EXCEPTIONAL CONDITION frame 
that results from the ANLZ "TCB CIDB) CUN" command. 


STAR DESCRIPTION RECOMMENDATIONS: 


1. Give the name of the dump file on your system and the patch Level 
run at your site. 


2. If possible, describe the process the user who caused the snap was 
attempting. Note that the identity of this user may be obtained by 
ANLZing the dump and entering the command "SPY CUN"”. 


Contact the user as soon as possible after the snap so that the 
details of what happened aren't obscured by the passage of time. 


SUPPORTING DOCUMENTATION: 
BEAM the information extracted from the dump file by ANLZ's command: 


STAR “Obtain information appropriate to the 
"type of dump file. 


A concise, readily transportable testcase that can be used to 
demonstrate the difficulty on the LADC support computer, if available 
will, generally, greatly reduce the time required for problem 
resolution. Note that for problems of this nature it's often necessary 
to duplicate the difficulty on the support system. Consequently, it may 
be necessary to transport Larger testcases on magnetic tape. It is also 
possible for support personnel to debug Large testcases on your system, 
if you are prepared to help set up the environment. 
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TPCP Snaps 


A TPCP snap is identified by the screech code QXA-xxx-5 indicating that the 
CP-6 TP command processor, TPCP, has encountered an abort condition. The dump 
file created documents the environment of the user using TPCP at the time of 
the failure. 
SUGGESTED STAR TITLE: <wsn> code @ ic 
where 
wsn is the site's workstation name. 


code is the screech code. 


ic is the instruction counter from the EXCEPTIONAL CONDITION frame 
that results from the ANLZ "TCB (ICP) CUN'' command. 


STAR DESCRIPTION RECOMMENDATIONS: 


1. Give the name of the dump file on your system and the patch Level 
run at your site. 


2. If possible, describe the process the user who caused the snap was 
attempting. 


SUPPORTING DOCUMENTATION: 
BEAM the following ANLZ documentation from the dump: 


SYM TPCP "Run-unit to reference for SYMDEF/ENTDEFs 
TCB CICP) "TPCP's TCB 


AUTO $LS4 FOR CUN,ICP WAPL ‘Formatted dump of TPCP's AUTO storage 


TPA Snaps 


A TPA snap, identified by the screech code QQ@C-752-5, occurs when the CP-6 TP 
processor, TPA, encounters an abnormal condition. The dump file that gets 


created documents the TPA's environment at the point the abnormal condition is 
detected. 
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SUGGESTED STAR TITLE: <wsn> QQC-752-5 @ ic 
where 
wsn is the site's workstation name. 


ic is the instruction counter from the EXCEPTIONAL CONDITION frame 
that results from the ANLZ "TCB"’ command. 


STAR DESCRIPTION RECOMMENDATIONS: 


Give the name of the dump file on your system and the patch Level run at 
your site. 


SUPPORTING DOCUMENTATION: 
BEAM the following ANLZ documentation from the dump: 


STAR "Obtain information appropriate to the 
"type of dump file. 


FEP Screeches 


As with host screeches, there is a wide variety of FEP screeches that may 
occur; a tailor-made procedure to identify all the information required to 
solve the problem is not possible. The information Listed below should be 
used as a guideline when submitting STARs to document a FEP problem. 
SUGGESTED STAR TITLE: <wsn> scode @ ic 
where 
wsn is the site's workstation name. 


scode is the screech code in the form mid-code-sev (e.g., GHT-1315-3). 


ic is the instruction counter from the REC display (e.g., KNASMCL + 
-50). 


STAR DESCRIPTION RECOMMENDATIONS: 


1. Give the name of the dump file on your system and the patch Level at 
your site. 


2. Describe any observable external conditions at the time of the 
problem. 
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SUPPORTING DOCUMENTATION: 
BEAM the following ANLZ information extracted from the dump file: 


REC 

PL .4000 FOR CUN 

DUA .nnnn, .1000 FOR CUN "where nnnn is the value displayed 
“for B7 in the REC command. 


TP Problems 


A TP problem can be one of the more difficult problems to diagnose because 
they normally involve separate processes that reside in the FEP and the host 
that must communicate to one another through a host resident comgroup. 
Consequently, there usually is much information that must be accumulated at 
the time the problem is occurring to adequately document the situation in both 
the FEP and host. As is the case with most difficult problems, a concise 
testcase that duplicates the difficulty usually requires a good deal of effort 
on the part of the customer and, more often than not, is elusive. However, 
such a testcase that can be transported to LADC as supporting documentation 
will greatly reduce the time necessary for problem resolution. 


SUGGESTED STAR TITLE: 
See the recommendations discussed for TITLE in "STAR Format and Content" 
STAR DESCRIPTION RECOMMENDATIONS: 


1. Identify the names of any dump files produced and indicate the patch 
Level run at your site. 


2. Identify the name of the TP instance and the associated TRADER file. 
3. Clearly describe the problem. 


If an application (host or FEP) abort is occurring, what messages 
are output to the TPA or Master Control Terminal (MCT)? What does 
the TP terminal user(s) experience? What is the situation with the 
TPAP? 


If the TP instance is hung, are there any messages that were output 
to the TPA or MCT? What is the state of the TP terminal users as 
determined via an <ESC Q> sequence? What is the state of the 
associated TPAPs (TPAPs may be identified in ANLZ with "SPY T" and 
their states can be determined with "USRT T")? What is the state of 
the TPA (the TPA may be identified with in ANLZ with "SPY CC=TPA" 
and its state can be determined with "USRT CC=TPA")? 
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4. If applicable, describe your attempts at running the application in 
the following modes: 


ie) 


Debugging the TPAP at a time-sharing terminal and using the FPRG 
as a time-sharing forms program (see Appendix H of the CP-6 FPL 
Reference, CE51). 


Debugging the TPAP at a time-sharing terminal with actual 
transaction 1/0 from the FPRG (see TPAP Debugging in the CP-6 TP 
Administrator Guide, CE50). 


Debugging the TPAP at a time-sharing terminal with simulated 
transaction 1/0 (see TPAP Debugging in the CP-6 TP Administrator 
Guide, CE50). 


Invoking the debugger for a TPAP operating in the TP mode and 
supplying debug commands in a file (see TPAP Debugging in the 
CP-6 TP Administrator Guide, CE50). 


SUPPORTING DOCUMENTATION: 


1. In the case of an abort and possibly for the TP hung situation, you 
need to identify the data necessary to duplicate the problem on your 
system. 


O 


oO 


oO 


oO 


ie) 


The XEQ file used to start the TP instance. 

FPRG source and run-unit. 

TPAP source and run-unit. 

TP terminal dialogue necessary to reproduce the difficulty. 


TP terminal logon. 


With the above documentation, indicate the Line number in the source 
files where the problem is occurring. 


2. In a TP hang situation, information should be gathered to document 
the problem while it is occurring into a DRIBBLE file. 


First, it's important to dump the TPA's host LDCT used to 
communicate with the FPRG. The following ANLZ commands accomplish 
this: 


SPY CC=TPA 
USRT .TPA-user# 
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"The pointer in the USRT display under MISC$ is usually is 
“the pointer to the host LDCT in the form .xxxxxx006013 
“where xxxxxx is the Ldct-offset. 


DUA $LS11->.Ldct-offset,.30 


"The first halfword of relative word 6 of the above display 
"is the LDCT index, lLdctx. 


LDCT .ldctx 


“The number of the FEP containing the user causing the TP 
“instance to hang is in byte 0 of relative word .15 of the 
“DUA display above and, also, in the LDCT display as the 
“first number under the RLCID heading. 


At this point, a dump of the TPA user should be obtained using the 
SNAP.X facility as follows: 


'SNAP.X - 
. TPA-user# — 


If the FEP holding the user causing the TP instance to hang can be 
conveniently crashed at this point, then do so from the system 
console to produce a dump file with the keyin 


'CRASH FEP n 


The following information should be extracted from the dumps 
produced and BEAMed to LADC. Also, if it was not possible to SNAP.X 
the TPA user or situations were such that the FEP could not 
conveniently be CRASHed, then the same information should be 
obtained while the hang is occurring. 


'ANLZ 
SEL HOST 


USRT .TPA-user# 

DCBS .TPA-user# 

TCB . TPA-user#. 

SSF $LS$37->.500 FOR .TPA-user# 
AUTO $LS16 FOR .TPA-user# WA 


SEL FEP 


SEL n 
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"The above command must be entered when obtaining the data 
“from a Live system at the time of the hang. n represents 
“the FEP number containing the FEP user causing the TP 
"instance to hang. 


SPY 


"From the "Identification' field in the above SPY, locate 
“the offending user by looking for a match with the field 
""DEVNAME' in the previous LDCT display. The ‘Usr#' in 
“the SPY for that user will be referred to as fepusr#. 


TSA .50B6 FOR’ .fepusr# 

TSA .50FF FOR’ .fepusr# 

PL .4000 FOR’ .fepusr# 

DUA .4400,.400 FOR’ .fepusr# 

JIT .fepusr# 

TCB .fepusr# 

ECCB .fepusr# 

DCBS .fepusr# "SSNS field to be referred to as ssnptr 
SSN .ssnptr "LDCT$ field to be referred to as ldctptr 
LDCT .ldctptr 

BOBCAT 

SFILE 

INTCON 

ACCRES 

MEMORY 

STAT 

PPUT 


Compiler Problems 


The STAR requirements for problems associated with the various CP-6 compilers 
or interpreters are essentially identical. 


SUGGESTED STAR TITLE: 


1. If no abort condition is associated with the difficulty, follow the 
guidelines for TITLE in "STAR Format and Content". 


2. In the event of a compiler abort, the TITLE should be of the form 
<wsn> code @ ic 
where 
wsn is the site's workstation name. 
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code is the monitor abort code. 


ic is the IC of the abort obtained from the diagnostics produced 
or by running the compiler under DELTA. 


STAR DESCRIPTION RECOMMENDATIONS: 
1. Indicate the patch Level run at your site. 


2. Describe the compiler's external diagnostics at the time of the 
failure. 


SUPPORTING DOCUMENTATION: 


Provide the source of the program that's causing the compiler 
difficulties. Be sure all the files necessary to reproduce the failure 
are identified. For example, if a COBOL source program references COPY 
files, state that and indicate where they may be found. 


The ideal situation would be to BEAM a single XEQ file that contains the 
entire source of the program and control commands necessary to reproduce 
the problem on the LADC system. 


Application Problems 


User application programs abort or have problems for a variety of reasons. 
Some of these are user errors including, for example, bad data or erroneous 
coding. Others involve problems with the CP-6 software including, for 
example, bad patches or software bugs. It is the user's responsibility to 
adequately debug an application difficulty to the extent that those dealing 
with user errors are eliminated. 


Such debugging will quite often isolate a difficulty that's not a user error 
to the degree that a concise testcase can be developed to demonstrate the 
problem. Doing so and BEAMing such a testcase as supporting documentation 
Will invariably significantly reduce the time required for problem resolution. 


SUGGESTED STAR TITLE: 


1. In the event of an abort condition in one of the CP-6 provided 
run-time Libraries, the following is recommended as a title: 


<wsn> code @ ic 
where 


wsn is the site's workstation name. 
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STAR 


ae 


code is the monitor abort code. 


-jic is the IC of the abort obtained by running the failing 
application under DELTA. 


If no abort condition is associated with the difficulty, follow the 
guidelines for TITLE in "STAR Format and Content" earlier in this 
section. 


DESCRIPTION RECOMMENDATIONS: 


Indicate the patch level run at your site. 
Identify the type of program that's failing. 


Describe the external symptoms of the failure including those seen 
when running the program under DELTA. 


Describe the failure in terms of the EDIT Line numbers from the 
source program file supplied as supporting documentation. 


Describe what changes on your system or in your program prompted the 
failure. 


SUPPORTING DOCUMENTATION: 


1. 


6-22 


Identify all the files required to generate the run unit(s) from 
source. This includes all the source, copy or include files and XEQ 
files to perform the necessary compilations and Links. 


Identify the run unit(s) involved. 


Identify an XEQ file required to reproduce the problem. The file 
should include the necessary SET commands that point to the data 
files involved. In addition, outline the terminal interactions that 
produce the failure. 


BEAM to LADC a DRIBBLE that shows the run unit failing while being 
run under DELTA. After the failure occurs, a PLUGH command should 
be entered. 


If a concise testcase that demonstrates the failure exists, BEAM it 
with all supporting documentation to LADC. 
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Identifying System's Patch Level 


The current patch level of the system is essential information to include when 
reporting a problem. 


For the CP-6 host system, enter 
'WHAT.X PA 


The resulting display gives the current patchweek number in the form yww, 
where y is the Last digit of the year and ww is the fiscal week number. 


For a tocal or a remote FEP, enter 
!DELTA 
>ANLZ FEP n 
>DUA G_PATCHWEEK, 2 


The desired FEP is indicated by n. The resulting display shows the 
current patchweek (yww) in decimal at the far right. 


The patch week information is also stored in the patch file, which is named 
:PFvvvx.:SYSTAC (where vvv is the system version [e.g., C01, DOO, etc.] and x 
is the tape boot sequence number for the site). In the current patch file, 
Look for Lines containing the string M B_SITEINFO. You will find a Line such 
as 


M B_SITEINFO+.70 


If you find that, the contents of B_SITEINFO are being modified to the value 
of the “current patchweek"’. For example, 


M B_SITEINFO+.70 '603' (°Q000') 


means that this :PF file was built using week 603 patches. 
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Identifying Dump File Version 


The form of a dump file name is :DFvvvxddd, where vvv is the system version 
(e.g., CO1, DOO, etc.); x is the same letter as the last Letter in the patch 
file (:PFvvvx.:SYSTAC) in use when the dump occurred; ddd is the numeric dump 
file identifier. 


To determine if a dump you are examining occurred under the current system 
patches, enter 


!OQUTPUT SVERSION 


The resulting display is the portion of the patch file fid that follows :PF. 
For example, if the current patch file is :PFDOO0d, the display is DOOd. 
Compare the x in :PFvvvx and :DFvvvxddd. If they are the same, then the dump 
file is from the currently installed patch week, which may be displayed as 
described above. 


Retaining Files in :SYSTAC and :SYSTAC2 


Reviewing the dump files in the :SYSTAC account is important for optimal 
problem reporting and also to ensure that dump files do not accumulate, using 
up too much space on DP#SYS. Dumps that do not represent true problems (for 
instance, the dump created by a ZAP) can be deleted. Also dump files for 
closed STARs, for duplicate problems, or for hardware problems can be deleted. 
Section 7 recommends techniques to track STARs that facilitate maintenance of 
dump files. 


Note: Retaining error log files in :SYSTAC for the previous week (Monday 
through Sunday) allows data gathering by the Early Warning System mentioned in 
Section 5. LADC schedules a deferred job that is queued for transmission on 
Wednesdays. That job is intended to pass the error Log data to the support 
computer while the customer obtains the current incremental patches via the 
synchronous connection. (A second job also sent from LADC collects a profile 
of the versions of the software products installed at your site.) Saving the 
error log data is voluntary for all sites. From sites that retain the error 
log files, LADC can accumulate a data base of Long-term stability data which 
can analyzed for stability trends. 


Optionally, your site can define a second account for storage of dump files. 
By convention, this account is called :SYSTAC2; it is defined on a packset 
other than DP#SYS, and has write access granted to the :SYSTAC account. If 
support personnel need to access your system for remote debugging, they will 
know to Look in either of those two accounts. In addition, ANLZ is designed 
to Look first in :SYSTAC and then in :SYSTAC2 for dump files. 
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Another optional naming convention that can help in maintaining dump files in 
2SYSTAC or :SYSTAC2 is to rename a dump file that is represented by a star so 
that its name begins with the STAR number. For instance, if the dump file is 
:DFDOOD024 and if the corresponding STAR number is 33555, the dump file name 
can be renamed as 33555 D024. This simplifies the task of identifying dumps 
that can be eliminated when a STAR is closed. 


zSYSTAC Cor :SYSTAC2, if it is used) should be included in regular account 
maintenance procedures: older dump files can be stored on tape for later 
retrieval. Dumps for unresolved STARs should be saved to the greatest extent 
possible for timely problem resolution. By monitoring STAR closures, as 
explained in Section 7, you may determine when dump files for those STARS are 
no longer needed and therefore should be deleted. 
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Section '7 


STARLOG Common Usage Considerations 


The following sub-sections provide examples of the more common tasks a 
customer will perform that are related to the STARLOG processor. This section 
is task-oriented: it describes the commands and features that are used most 
often. For a complete discussion of the STARLOG data base and command syntax, 
see Appendixes A and B in this handbook. 


Note that two formats are often given for the commands that are demonstrated. 
One using the unabbreviated commands and the second the short-hand notation. 
The short-hand versions shown will, when possible, concatenate multiple 
commands using the STARLOG command concatenation symbol, "."'. 


Modifying Your LOGON Record 


One reason for modifying the LOGON record is to change the NAME field. This 
field contains the default name associated with a STAR you create or a NOTE 
you append. It is recommended that customers use their first and last name 
and identify their site by enclosing the WSN associated with their site in. 
parentheses. 


For example, suppose a user, Jim Smith, working for company called Xylo Yellow 
Zippers with a WSN XYZ wishes to make the changes suggested above when Logging 
on to STARLOG for the first time. He must first use the FIND command to 
Locate or position to his LOGON record. Once positioned there, fields within 
the LOGON record may be modified with the CHANGE command. For example, the 
following commands will accomplish the suggested task: 


#FIND LOGON:SYS NUM IS ssssss 
#CHANGE LOGON: NAME TO ‘Jim Smith (XYZ)' 


or, alternatively, 

#FI LOGON:SYS NUM IS ssssss.CH NAME TO ‘Jim Smith (XYZ)' 
where ssssss is the customer's site ID or system number (e.g., CX0003). 
Note, also, that STARLOG permits modification of existing data in a field Like 
LOGON's NAME through use of the EDIT command. For example, suppose Jim 
Smith's LOGON NAME was ‘Jim Smith' and he wanted to change it to ‘Jim Smith 


(XYZ)'. An alternative to the CHANGE command, assuming he's positioned to his 
LOGON record, is 
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#ED NAME 
at which point the following is output 

Name: Jim Smith 
The system's terminal input editing features can then be used to alter the 
contents of the NAME field. In this case, the cursor would be positioned 
after the name ‘Jim Smith'. To make the necessary changes, enter (XYZ) 
followed by a carriage return. 
The user may also wish to have STARLOG automatically execute a command at the 
start of each on-line session. The following commands cause. a change to the 


"first command" in the user's LOGON record: 


#FI LOGON: SYS NUM IS ssssss =. 
#CH FIRST COMMAND TO 'WHEN STAR: STAR. WHEN FIND STAR:STAR' 


where ssssss is the customer's site ID or system number. These sample 
commands cause the STAR report to be displayed each time the user steps to or 
finds a STAR. 
Displaying STARs 
In order to display a STAR, or for that matter to perform any operation on a 
STAR, it's necessary to be positioned to it by means of the following #FIND 
command: 

#FI STAR:NUMBER IS nnnnn 
where nnnnn is the number of the STAR. 


Alternatively, one may position to the STAR by just entering the STAR number. 


Once positioned to the appropriate STAR, there are a number of reports that 
are available. They're all invoked with the command: 


AREPORT rptname 
or, more simply, 
#rptname 
where rptname may be any of the following: 


STARSUM - generates a one Line summary of pertinent information 
contained in the STAR. 
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STARNOTE - generates the one Line STARSUM report followed by all the 
NOTES in the STAR. 


STAR = generates the most complete report available for a STAR with 
all pertinent information contained in the heading followed 
by the description and all the NOTEs. 

STARONLY - generates the standard STAR report without the NOTEs. 


STARPAGE - generates the standard STAR report beginning each at the top 


of page. 
Note that the command necessary to generate each of the reports above may be 
abbreviated to "rptname''. For example, to display STAR nnnnn either sets of 
commands 


#FI STAR:NUMBER IS nnnnn 
#REPORT STAR 


or 
#nnnnn.STAR 


may be entered. Sample displays will be shown in the following sections. 


Building a STAR 


To enter a STAR, the command “BUILD STAR" or, more simply, "BU STAR" is used. 
The following illustrates the interactions necessary for Jim Smith at a site 
known as XYZ to accomplish the task: 


#BU STAR 

Subject name: CENTRAL 

Subject version: C01 

Originator Name: 

Severity: 2 

Title: <XYZ> UDE-501-7 @ KQTSTREES+.2222 
Star number: 1234 


Description: 

-The screech occurred during a ZAP of the system. After recovery, 
-another ZAP proceeded without incident. Preliminary analysis 
-information will be beamed to 1234 ANLZ.ZZZTEST. The dump @XYZ is 
-1234_A004.:SYSTAC2. We're currently running on week 702 patches. 


# 
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Note that just a carriage return was entered in response to the prompt for the 
originator's name. The name in this case will be the one stored in the user's 
LOGON record. 


Note: Because STARLOG can interpret the command variables the percent 
character (4) must be entered as 4% when building STARs and NOTEs. 


For a List of the legal subject names and the meaning of the various severity 
codes, see Appendix A. 


After entering the above STAR, a STAR display would appear as in Figure 7-1. 


#1234.STAR 

Number:1234 UNREV (2) Date 02/26/87 09:45 Subject: CO1 CENTRAL 
Title: <XYZ> UDE-501-7 @ KQTSTREES+.2222 
By: Jim Smith (XYZ) Cust: Xylo Yellow Zippers To: UNASSIGNED 


The screech occurred during a ZAP of the system. After recovery, 
another ZAP proceeded without incident. Preliminary analysis 
information will be beamed to 1234 ANLZ.ZZZTEST. The dump @XYZ is 
1234 _A004.:SYSTAC2. We're currently running on week 702 patches. 


Number: 1234 UNREV (2) To: UNASSIGNED Subject: CO1 CENTRAL 
# 


Figure 7-1. STAR Display After BUILD 


Note that the status of the STAR at this point is UNREV or UNREVIEWED and, 
consequently, is only visible to the submitter, the TAC and LADC developers. 
Only after the Starlord, currently a member of the CP-6 TAC, reviews the 
STAR's content and changes the status to OPEN, will it be visible to others. 
If the documentation mentioned in the STAR description has not arrived when 
the Starlord reviews it, the status will be changed to DOCUM, meaning that 
STAR problem analysis is put on hold pending receipt of the documentation. 


Also, note that the ASSIGNED PROGRAMMER, the TO: field in the STAR's display 
header, is UNASSIGNED. Within 15 minutes an automated process known as 
STARGAZE will detect that a new STAR has been submitted and make the necessary 
programmer assignment. 
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Editing a STAR 


After entering a STAR, it may be necessary to alter the description or any of 
the associated fields. It is advisable to perform any editing of the STAR 
immediately after entering it; otherwise Support personnel will have no reason 
to notice that changes were made. 


Assuming the user has already positioned to the STAR or has just completed 
building it, then the following demonstrates how to modify the description of 
the STAR entered in the last section: 


#ED DESC 

Text: 

EDIT CO1 Here 

*SE4;/A004/S/A005/;TS | 
1234 _A005.:SYSTAC2. We're currently running on week 702 patches. 
*END 

# 


The EDIT processor is entered to permit the user to perform alterations to the 
STAR description. Prior to entering EDIT, STARLOG writes the description to a 
temporary keyed file called xSTAREDIT which the user then modifies. 


Suppose the severity of the STAR is to be changed from 2 to 3. The following 
command accomplishes this task when positioned at the STAR: 


#CH SEV TO 3 
Suppose the TITLE needs to be changed from "<XYZ> UDE-501-7 @ KQTSTREES+.2222" 
to ''<XYZ> UDE-501-7 @ KQTSTREES+.1111". Two commands are available. The 
CHANGE command to perform the task is 

#CH TITLE TO '<XYZ> UDE-501-7 @ KQTS$TREES+.1111' 
The alternative is the EDIT command: 

#ED TITLE 

Title: <XYZ> UDE-501-7 @ KQTSTREES+.2222 
Your terminal cursor will be positioned at the end of the above title Line and 
input editing may be used to alter the title to what is desired. In this 


case, four DEL characters, four new characters and a carriage return 
accomplish the task. 
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Assuming that the above editing has been performed, the Starlord has reviewed 
the STAR and the documentation has been delivered to the support computer, 
then the STAR display appears as in Figure 7-2. 


#1234.STAR 

Number:1234 OPEN (3) Date 02/26/87 09:45 Subject: CO1 CENTRAL 
Title: <XYZ> UDE-501-7 @ KQTSTREES+.1111 

By: Jim Smith (XYZ) Cust: Xylo Yellow Zippers’ To: 


The screech occurred during a ZAP of the system. After recovery, 
another ZAP proceeded without incident. Preliminary analysis 
information will be beamed to 1234 ANLZ.ZZZTEST. The dump @XYZ is 


1234 _A005.:SYSTAC2. We're currently running on week 702 patches. 


Note: 1 Type: Name: TATTLE <TESTCASE> Date: 02/27/87 23:10 
These testcases have arrived in ZZZTEST @LADC 
1234 _ANLZ 


Number: 1254 OPEN (3) To: Subject: CO1 CENTRAL 
# 


Figure 7-2. Display of Completed STAR 


Note that the delivery of the testcase is noted by the automated process 
called TATTLE which in addition to appending the note, OPENs the STAR and 
sends a MAIL message to the responsible programmer. Also notice that after 
the STAR is assigned to a programmer, the "'To:" field changed from UNASSIGNED 
to blanks. (The assigned programmer name is not visible to customers. ) 


Appending NOTEs 


Information is added to existing STARS by means of NOTES. To add a NOTE to a 
STAR, one must be positioned to the STAR. Suppose our chap Jim Smith wants to 
inform all that the screech he experienced and reported in the previous 
sections has occurred again. The following sequence is necessary: 


— #1234.BU NOTE 
Name: 
Type: 
NOTE number: 2 
-The problem occurred again (see dump 1234 _B0034.:SYSTAC). 
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Support personnel may not notice notes that are added to STARs that are 
closed. It is important not to append notes to closed STARs unless you are 
claiming that the STAR is still a problem and should be reopened. 


Editing a NOTE 


In order to EDIT a NOTE, it is first necessary to position oneself to the STAR 
and then position to the NOTE that needs modification. Positioning to a NOTE 
is done similarly to positioning to a STAR. It is advisable to perform any 
editing of a note immediately after entering it; otherwise Support personnel 
will have no reason to notice that changes were made. If time has lapsed 
since you entered your note and you now wish to amend it, append a new note to 
the STAR rather than editing a prior note. 


The commands required to modify the NOTE entered in the Last section are 


#FIND STAR: NUM=1234 
#FIND NOTE:NUM=2 
HEDIT TEXT 


or, more simply, 
#1234.:2.ED TEXT 


Note that the command :2 serves as an abbreviated form for the FIND NOTE 
command. After entering the above commands, the text of the NOTE is written 
to a temporary keyed file called *STAREDIT and the CP-6 EDIT processor is 
entered to permit modification to proceed. For example, 


#1234.:2.ED TEXT 

Text: 

EDIT CQ1 Here 

*/0034/s/003/;tx 

1.000 The problem occurred again (see dump 1234 B003.:SYSTAC). 
*xQ 

# 


Of course, immediately after building a NOTE it would not be necessary to 
position to the STAR and then the NOTE as has been shown. This was done just 
for purposes of demonstration. 


Figure 7-3 shows the STARNOTE display for the STAR 1234 after the NOTE has 
been edited. The NOTE at this point shows a type field with parentheses. 
This is an indication that it has yet to be reviewed by the Starlord and, 
until it is, is only visible to the submitter, the CP-6 TAC and LADC 
developers. 


STARLOG USAGE 
CE61-01 7-7 


#1234.STARNOTE 
1234 OPEN 3 02/26 C01 CENTRAL <XYZ> UDE-501-7 @ KQTSTREES+.1111 


Note: 1 Type: Name: TATTLE <TESTCASE> Date: 02/27/87 23:10 
These testcases have arrived in ZZZTEST @LADC 


1234_ANLZ 


Note: 2 Type: ( ) Name: Jim Smith (XYZ) Date: 02/29/87 08:12 
The problem occurred again (see dump 1234 BO03.:SYSTAC). 


Figure 7-3. STARNOTE STAR Display 


Deleting a STAR or NOTE 


In some cases you may find it necessary to delete a STAR that you have built. 
In this case, build a note specifying F as the note type. The Startord will 
void the STAR for you. 


If you have just entered a note and discover it is for the wrong STAR, for 
example, you can edit the note's type code, changing it to X. The Starlord 
will void the note. 


Duplicating STARs 


Frequently more than one customer will discover the same problem. When two 
STARS representing the same problem are entered, the later STAR is closed as a 
duplicate (CLDUP) of the first. It is important to understand that a CLDUP 
status does not mean that the problem is being ignored. Instead, it is being 
followed under a different STAR number. ‘Common STAR Retrieval Functions", 
example 8 discusses a technique for tracking duplicate STARs. 


If you are aware that a problem already exists and know the STAR number, you 
are encouraged to join in the dialogue by adding a note. Appending a note 
with the words ''Me Too" indicates that the STAR also represents a problem for 
your site. (If the site originating the STAR is unable to reproduce the 
problem but your site can, it is very helpful to state this in your note and 
to supply the appropriate supporting documentation.) If a suggested 
improvement agrees with your site's requirements, you could add a note saying 
"Me Too - suggested fix in Note 3", for example. 
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Common STAR Retrieval Functions 


One of the obvious benefits of STARLOG is that it serves as a extremely useful 
repository of work-arounds and solutions for known problems. As a result, it 
frequently is necessary to scan the STARBASE for STARs that meet a variety of 
criteria. The following examples demonstrate some of the more common 
‘techniques for extracting the STAR numbers of those that meet the criteria 
specified. 


1. Suppose you want a List of all COBOL STARs whose TITLE contains the word 
COMPUTE. 


ASTARSUM SUNA IS COBOL & TITLE CONTAINS COMPUTE 
Here SUNA iS an abbreviation for SUBJECT NAME. 


2. Suppose you want a List of all FEP STARs whose number is greater than 
30000 whose TITLE contains GHT or GHS. 


#30000.STARSUM REST SUNA IS FEP & (TITLE CONTAINS GHT | GHS) 


Here you must first position to STAR 30000 and then request that the 
search proceed forward from that point via the REST keyword looking for 
STARS that satisfy the criteria specified. This technique is useful when 
you know the STAR's number is in a particular range since you eliminate 
the need to scan those that exist with a number less than or equal to 
30000. 


3. Suppose you want a List of all STARs with "Analyst Alert" status for the 
DOO version of the operating system. 


#STARSUM SEV IS A & SUBJ VERSION IS DOO 

4. Suppose you want a List of all STARs you submitted that are not closed. 
#STARSUM ORNA IS ME & STATUS IS NOT CL 
The symbol ORNA is an abbreviation for ORIGINATOR NAME and ME is a special 
STARLOG keyword that specifies the user's customer site name or Logon name 
depending on the associated context. In this case, it’s Logon name; if 
instead of ORNA, ORCU SITE NAME (ORIGINATING CUSTOMER SITE NAME) had been 
used, then ME would refer to the customer site name.- That is, the command 


#STARSUM ORCU SITE NAME IS ME & STATUS IS NOT CL 


will List all STARS submitted by your site that are not yet closed. 
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Suppose you want a List of atl STARs that have been submitted by your site 
and have been modified since being Logged on Last. 


#STARSUM ORCU SITE NAME IS ME & MOD DATE >= MY TIME 


MOD DATE refers to the STAR's Last modification date. This contains the 
time when modification of the STAR's title, description, status or 
severity last occurred or a NOTE was Last appended or modified. 


Two fields that exist in your LOGON record are MY TIME and LAST LOGON 
TIME. Both are used to hold the time of the last logon. The difference 
is that MY TIME is controlled by the way you terminate your STARLOG 
session. If END HOLD is entered to terminate a session, then the LAST 
LOGON TIME is updated but MY TIME is not. This provides you with a means 
of preserving the real LAST LOGON TIME, if a session was initiated and 
terminated for reasons other than finding STARs modified since the Last 
Logon. 


Note: To edit the MY TIME field in case it is inadvertently updated, use 
the EDIT LOGON:MYTIME command to reset the field to the value when the 
Last reporting job was run. 


Suppose you want a List of all EFT or FILE STARS whose TITLE, DESCRIPTION 
or any NOTE's TEXT contains ARCHIVE. 


#STARSUM (SUNA IS EFT | FILE) & ((TITLE CONTAINS ARCHIVE) | (DESC CONTAINS 
ARCHIVE) | (NOTE: TEXT CONTAINS ARCHIVE) ) 


Suppose you want a summary of all STAR activity occurring in the Last 
week, that is, a Listing of STARs that are new, had notes added, had the 
status changed, etc. Since the report from these command is most useful 
in hard copy form, the commands are shown as a JCL file to be submitted 
for execution in batch mode. 


1.000 !STARLOG 
2.000 STARSUM REST NUM > 25000 AND MOD DATE >= WEEK AGO 
3.000 END 


The report STARSUM command asks for summaries of STARS with a STAR number 
greater than 25000 and a modification date within the Last seven days. 
Starting the search at 25000 saves time, since few STARS below that number 
Will have significant activity. This type of search is often best 
performed in batch mode, as discussed and illustrated in the next 
subsection. 


Suppose you want a summary of NOTE activity on a set of STARs that are of 
interest to your site. 
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1.000 !STARLOG 
2.000 WHEN FIND STAR: STARSUM 
3.000 WHEN STEP STAR: STARSUM 
4.000 SELECT NOTE:DATE >= WEEK AGO 

29479 .000 29479.NOTE 

29581.000 29581 

29581.100 26586.NOTE 

32063.000 32063.NOTE 

32150.000 32150.NOTE 

99999 .000 END 


This JCL file uses two WHEN commands to request Summary reports and a 
SELECT command to request printing of only NOTES added or changed within 
the Last week. The individual STARs for which notes are to be printed are 
entered in the JCL file with an edit key that is the same as the STAR 
number. This use of edit keys facilitates finding and deleting STAR 
numbers, once a STAR is closed or no Longer of interest. To track STARS 
that are "closed duplicate", the CLDUP STAR number is left in the JCL file 
(for example, 29581) without the .NOTE command, and following it at the 
next .1 increment, the number of the open STAR that represents the problem 
of interest is entered with the NOTE command. This sequence causes the 
CLDUP STAR summary to print, followed by the STAR summary of the open STAR 
and any notes from the past week. 


See the following subsection for information on submitting batch jobs to 
STARLOG. 


Creating STARLOG Reports in Batch Mode 


When using STARLOG for extensive searches of the STARBASE, it is usually | 
advisable to transmit a batch job request to the support computer, using the 
IBEX command, XMIT. For example: 


'XMIT fid to JE@LADC 
where 
fid identifies a JCL file. 


The next time your site dials up the LADC support computer, the JCL file from 
your site is sent and scheduled for execution. The JCL file such as the one 
in Figure 7-5, produces a STARLOG report which is automatically sent back to 
your site the next time your site dials up the support computer. Your STARLOG 
report then prints on your site's LOCAL Line printer. Notice that the JCL 
file in Figure 7-5 does not contain an OUTPUT command and does not identify a 
WSN on the JOB card. 
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Scheduling STARLOG Batch Job via SETUP File 


The SETUP command file used on the customer site by the system manager (or 
primary technical contact) can include the XMIT command that schedules the 
STARLOG job on a weekly basis. This is done via IBEX and LASTLOG.X commands 
in the SETUP file. In Figure 7-4, the STARLOG job would be transmitted when 
you dial up the support computer on Monday; output from the job would be sent 
back to your site when you dial up the support computer after the the job 
completes, which could be the following day. 


'LASTLOG.X 


‘IF STEPCC>O THEN GOTO Logged-on-once 
'IF $DAY = "MON' THEN XMIT star_job_fid to JE@LADC 


Figure 7-4. Sample SETUP File for System Manager 


Sample Weekly STARLOG Job 


The following figure illustrates a sample weekly STARLOG job. This job 
generates several reports that summarize STARLOG activity in the previous week 
and reports the new notes for a specific set of STARs. You may adapt this job 
to report the STARs of particular interest to your site. 


“SAMPLE WEEKLY STARLOG JOB 


"In the JOB command, specify your Logon 
"account ,uname ,password 

“which is necessary to gain access to 
"STARLOG. AS a courtesy, please defer 


“your job to run between these times: 
"17:00 - 23:59 or 0:00 - 7:00. 

'JOB account,uname,password NAME=STAR_WEEKLY, DEFER(22:00) 
"Always specify STAR=1, which is a pseudo 
"resource required by STARLOG jobs. 


Figure 7-5. Sample Weekly STARLOG Job (cont. next page) 
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'RES TIME=20, MEM=128, STAR=1 
"Invoke STARLOG. 

'STARLOG 
"Report a summary of my site's STARS 
"that are not yet closed. See Common 
"STAR Retrieval Functions, example 4, 
“for details. 

STARSUM ORIG CUST SITE ME & STATUS IS NOT CL 

PAGE 


“Report any ‘Analyst Alert" STARS with 


“activity in the previous month. 
STAR REST SEV IS A AND MOD DATE >= MONTH AGO 
PAGE 


“Report a summary of all STARs that 

"had a modification in the past week. 
"See Common STAR Retrieval Functions, 
“example 7, for details. 

"This sample uses the Literal WEEK AGO, 
“but an explicit date or the Literal 

"MY TIME could be used. For information 
“about using MY TIME, please refer to 


“Common STAR Retrieval Functions, example 
"5 7 


"By scanning the summary report of STAR 
“activity, it is possible to determine 
“which STARS to examine further when 
"accessing STARLOG online. 

WHEN FIND STAR: REPORT STARSUM 

WHEN STEP STAR:REPORT STARSUM 

SELECT MOD DATE >= WEEK AGO 

FIND NUMBER = 14594 

NEXT 

REST 

PAGE 


"Report a summary of specified STARs and 
“print any notes added or changed in the 
"past week. See Common STAR Retrieval 
“Functions, example 8. 
WHEN STEP REPORT STARSUM 
WHEN FIND REPORT STARSUM 
SELECT NOTE:DATE >= WEEK AGO 


“The STAR numbers Listed are those of 
“particular interest to your site. The 


Figure 7-5. Sample Weekly STARLOG Job (cont. next page) 
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"List typically includes STARs you submitted. 
“that are SEVERITY 4 or higher. See 
“example 8, Common STAR Retrieval 

“Functions, for a more detailed discussion. 
“By following the activity on these STARs 
"it is possible to see that a patch is 
“available, more problem documentation 

"is requested, the STAR is closed, etc. 

“The summary reports generated at the 


“beginning of this job are useful in 
“keeping this List of STAR numbers up to 
“date. 


29479 .NOTE 
29581 
26586.NOTE 
31932 .NOTE 
32063.NOTE 
32149 .NOTE 
32150.NOTE 
END 


Figure 7-5. Sample Weekly STARLOG Job 


Sample Monthly STARLOG Job 


The Figure 7-6 illustrates a sample monthly STARLOG job. This job generates a 
summary of STARLOG activity in the previous month for products in use at your 
site. This job also produces a summary file that is BEAMed back to your site 
for reference. Should a user report a problem with a specific processor, you 
can search the current STARSUM file for that subject name to determine if 
another site has previously identified the problem, then access STARLOG online 
to view the STAR description and all current notes. 


Note: Obtaining a STARSUM report rather than a voluminous STAR report is 
advisable. In addition, producing STARSUM reports for multiple subjects, 
rather than separate reports for particular subjects, is requested because 
multiple searches are very time-consuming. . 


This job also generates a STAR report for any "Analyst Alert" STARS that were 
created or modified in the Last month. 
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"SAMPLE MONTHLY STARLOG JOB 


'JOB account ,uname,password NAME=STAR_WEEKLY, DEFER(22:00) 
‘RES TIME=20, MEM=128, STAR=1 
'STARLOG 
"Direct output to a temporary file. 
OUTPUT INTO *FILE . 
"Obtain a STARSUM report, starting the 
"search at 25000, for activity in the Last 
"month for the subjects not excluded by 
“the clauses "SUNA IS NOT ...°. 
STARSUM REST NUM > 25000 AND MOD DATE >= MONTH AGO AND ; 
SUNA IS NOT IDP AND 
SUNA IS NOT IDS AND 
SUNA IS NOT RPG AND 
SUNA IS NOT HDLCX25 AND ; 
SUNA IS NOT X29 
"Obtain a STAR report of ‘Analyst Alert' 
“STARS with activity in the Last month, 
“except for subjects specifically excluded 
“by SUNA IS NOT... clauses. 
STAR REST > 25000 MOD DATE >= MONTH AGO AND SEVERITY IS A AND ; 
SUNA IS IDP AND 
SUNA IS IDS AND 
SUNA IS RPG AND 
SUNA IS HDLCX25 
SUNA IS X29 
END 
“BEAM the temporary file to your site 
"Cidentified by your workstation name). 
"Specify the Logon account, user name 
"and password to allow the file to be 
“"BEAMed. The file will appear with a 
"name of the form ‘date _STARSUM' in your 
"account :SYSTAC. 
'LET FIDSTR = 'ZCS$DATE)'I 1" STARSUM' 
'BEAM xFILE OVER ZFIDSTR.:SYSTAC @your_site_wsn 
account ,uname 
password 


Figure 7-6. Sample Monthly STARLOG Job 
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Sending Supporting Documentation 


Often the supporting documentation for a STAR is many Lines long. To avoid 
creating voluminous STARS, it is preferable to send this information to the 
-ZZZTEST account on LADC's support computer. 


The supporting documentation may be BEAMed to the CP-6 support computer. It 
is also possible to transmit a job to the support computer that builds a STAR 
and contains the supporting documentation. Both techniques are discussed in 
Later headings. 


Naming Convention for Supporting Documentation 


The name of the supporting documentation or testcases for a STAR should be of 
the form: 


starnumber_processorname 


For instance, for ANLZ information related to STAR 30333, the the supporting 
documentation file should be sent to 30333 _ANLZ.ZZZTEST. A DRIBBLE file for 
STAR 33444 should be sent to 33444 DRIBBLE.ZZZTEST. 


The STAR number at the beginning of the file name allows TATTLE to report the 
arrival of the testcase in the .ZZZTEST account by appending a note to the 
STAR. 


BEAMing Supporting Documentation 


To BEAM supporting documentation from a customer system to LADC's support 
computer, enter the BEAM command. For example, to BEAM the file *STARINFO 
created via ANLZ's STAR command, the customer enters 


'BEAM xSTARINFO OVER starnumber_ANLZ.ZZZTEST @LADC 


using the STAR number and underscore as the first portion of the file name 
(for example, 33555 ANLZ for STAR 33555). 


When requested, enter your logon account,name and next your password. As soon 
as the synchronous connection is made (see Section 5, "SYNC Capabilities"), 
the file is transferred. 


It is also possible to use a PC to perform file regenera as discussed in 
Section 5, "ASYNC Capabilities”. 
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Building STAR and Supporting Documentation in Batch Mode 


It may be convenient to create a job on the customer system that contains the 
STARLOG commands to build a STAR, and also contains the supporting 
documentation. That job can be scheduled for execution on the CP-6 support 
computer (as described in the heading above "Creating STARLOG Reports in Batch 
Mode"). 


Figure 7-7 shows such a job in abbreviated form. The job includes the 
commands to enter STARLOG, build a STAR, and exit STARLOG. Following that, it 
includes a COPY command and ANLZ supporting documentation (merged by from the 
*STARINFO file). In this sample, there is also another COPY command and a 
DRIBBLE file testcase (merged from an ELBBIRDed file). The COPY commands use 
the command variable LAST_STAR to include the STAR number in the file name of 
the files copied to .ZZZTEST. 


'JOB account,uname,password NAME=STAR_BUILDER 
'RES TIME=20, MEM=128, STAR=1 

'STARLOG 

BUILD STAR 

CENTRAL 

DOO 


4 
<XYZ> UDE-501-7, IC=FMCSRELCACHE +.27 
Time Dump File Node Comment 


04/21/87 12:52 star_H036 

04/21/87 14:09 star_H038 

Occurred running under patchweek 715. 
-END 

END 

‘COPY ME OVER ZC(LAST_STARI1_ANLZ).ZZZTEST 


(Here merge the xSTARINFO file produced via ANLZ) 


!COPY ME OVER Z(LAST_STARI |_DRIBBLE) .ZZ2ZTEST 


Figure 7-7. Sample JCL to Build STAR and Supporting Documentation (cont. next 
page) 
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(Here merge a DRIBBLE file that has been processed via ELBBIRD.X) 


‘EOD 


Figure 7-7. Sample JCL to Build STAR and Supporting Documentation 
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Appendix A 


STARLOG Data Base 


The major areas are STAR, PRODUCT, CUSTOMER, PROGRAMMER, CATEGORY, and LOGON. 
The [STAR] NOTE area is a sub-area of the STAR area, the [PRODUCT] VERSION 
area is sub-area of the PRODUCT area. Pictorially, this is represented in 
Figure A-1. 


STARBASE 
| 
| 
| | | 


i | | | | 
STAR CUSTOMER PRODUCT PROGRAMMER LOGON CATEGORY 
| I 
| | 
NOTE VERSION 


Figure A-1. STARLOG Area Structure 


Position is established in any of these areas by finding or Locating a record 
within the area. It may be assumed that each area contains a record of the 
same name as the area. For example, the STAR record is the only record in the 
STAR area. The major areas are independent of one another in that current 
position may be established for each simultaneously. The current position in 
a sub-area, however, is dependent on the current position of the area to which 
it is subordinate. For example, the current position for the NOTE area must 
be a NOTE record in the current STAR. 


Also, position may be established in a major area through use of a field in 
another area. For example, you'll see that the STAR record contains a pointer 
to the customer record in the CUSTOMER area for the STAR's submitter. STARs 
may be positioned to on the basis of the name field in the LOGON area (by 
ORIGINATOR NAME). . 


The current position in the STAR area may be determined via the STARSUM report 
and in the NOTE area via the NOTE report. 


STARLOG maintains a "default area'’ which changes whenever a FIND, SELECT or 
step command is executed. Subsequent commands which do not specify an area 
are defaulted to this area. The initial default area upon Logging on is STAR. 
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Each of the areas’ records have fields that may be referenced by users in 
STARLOG commands that retrieve information on the basis of user specified 
criteria. The areas and their corresponding records that are of concern to 
customers interested in pursuing their normal day to day CP-6 support 
responsibilities are STAR, NOTE, CUSTOMER and LOGON. 


STAR Area 
The STAR area contains a number of fields in its record that describe the 
entire content of a STAR except for the notes. Table A-1 describes all the 


STAR record fields. Note that each field name is shown with the minimum 
abbreviation that STARLOG accepts. 


Table A-1. STAR Record Fields 


[AS[SIGNED]] PROG[RAMMER] pfn 
This field points to the appropriate record in the PROGRAMMER area 
that identifies the LADC developer who has responsibility for the 
STAR. 
pfn represents the programmer field name through which STARS may be 
positioned. 


[CUR[RENT]] STAT[US] 


Current state of the STAR (see STAR statuses in Table A-10). 


DESC[RIPTION] 


Detailed description of the reported difficulty. The description may 
consist of multiple Lines. 


MOD[IFICATION] DA[TE] 


Date at which any of the following were changed: 


STARLOG DATA BASE 
A-2 CE61-01 


Table A-1. STAR Record Fields (cont) 


DESCRIPTION 

SEVERITY 

CURRENT STATUS 

ASSIGNED PROGRAMMER 

NOTE: TEXT 

the STAR was built or a NOTE appended. 
{NUM[BER ]!1NO} 


STAR number (assigned by STARLOG) 


NOTLE] snfn 


This field points to the NOTEs for this STAR contained in the NOTE 
area. 


snfn represents any STAR note field name by which STARS may be 
referenced. For example, STARS may be positioned to on the basis of 
NOTES that have your NAME (i.e., NOTE:NAME) 

OR[IGIN] DA[TE] 


STARLOG supplied data representing the date the STAR was submitted. 


OR[IGINATOR] CU[STOMER] cafn 


The field points to the record in the CUSTOMER area that identifies 
the submitter of the STAR. 


cafn represents any CUSTOMER area field name. STAR(s) may be 
referenced by any field in the CUSTOMER record of the submitter. For 
example, it is possible to find all STARs with an OR CU SITE NAME of 
XYZ Sz 
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Table A-1. STAR Record Fields (cont) 


OR[LIGINATOR] NA[ME] 
Name of the STAR submitter as supplied at the time the STAR was 
created. 
SEV[ERITY ] 
1-4 indicates the user's perceived impact of problem (see the List 
of STAR severities in Table A-9). 
5 indicates a desired improvement request. 
A is an ANALYST ALERT providing technical information or warnings. 
D is used for discussions or status STARS. 
SU[BJECT] NA[ME] 
Problem's subject category, e.g., FORTRAN, FILE. For the List of 
subject names, see Table A-8. 
SU[BJECT] VERS[ION] 
Problem's subject version, e.g., DOO for the DOO operating system, B06 


for the B06 version of a compiler or processor, 01 for the 01 version 
of a reference manual. 


ST[ATUS] CO[DE] 


Internal code representing the STAR's current state. 


TI[TLE] 


One Line description of the problem containing up to 60 characters. 


VIS[IBILITY] DA[TE] 


Date the STAR was reviewed (i.e., made visible to other customers. 
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NOTE Area 


The NOTE area, as has already been mentioned, is a sub-area of the STAR area. 
The records in the area contain the data that users append to STARs as 
additional information. Table A-2 describes the fields that are in the NOTE 
record. 


Table A-2. NOTE Record Fields 


DA[TE] 


Date the NOTE was entered or reviewed. 


LOG[ON] Lfn 


This field points to the LOGON record for the NOTE’s originator. 


lfn represents any LOGON field name that may be used to position 
NOTEs. 


NA[ME] 


Name entered when the NOTE was created. 


{NUM[BER]1NO} 


Number of the NOTE as assigned by STARLOG. 


TEXT 


Multiple Lines of text. 


TY[PE] 


Code entered at the time the NOTE is entered in response to the 
"Type:" prompt: 
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Table A-2. NOTE Record Fields (cont) 


blank - indicates a NOTE that may be entered by any user 


with added information or questions. 

FLORGET ] - indicates that STAR is to be ignored and may be 
entered by the originator only. 

R[ESPONSE ] - provides the LADC developer a means of 
acknowledgement. 


DEISPOSITION] - indicates the NOTE provides a resolution for 
the problem reported. Entered by LADC programmers or 


CP-6 TAC. 
ALVOID] - provides a means to avoid or work-around the 
problem. Entered by LADC programmers or CP-6 TAC. 
I[NVISIBLE] - indicates that the NOTE is visible only to LADC 


programmers and CP-6 TAC. These are used for internal 
discussions related to the problem reported. These 
and "H'' type NOTEs cause the customers to see "gaps" 
in the successive NOTE numbers that appear in STAR 


displays. 

H[ONEYWELL ] - indicates a NOTE entered by and only visible to 
Honeywell Bull personnel. 

X - indicates that the NOTE is to be ignored and 


may be entered the originator only. 


CUSTOMER Area 


The CUSTOMER area data describes the characteristics of CP-6 customers. Table 
A-3 contains a description of the various fields in this area. 
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Table A-3. CUSTOMER Record Fields | 


COMP[UTER] INFO[RMATION] 
COMP[UTER] [SIGN[ON]] ACC[OUNT] 
COMP[UTER] [SIGN[ON]] NA[ME] 
COMP[UTER] [SIGN[ON]] PASS[WORD] 
COMP[UTER] TEL[EPHONE] 


CONT[LACT ] NA[ME ] 


Name of the primary contact at the site. 


CONT[ACT] TEL[EPHONE] 


Phone number of the primary contact at the site. 


COST CEN[TER] 


The Honeywell Bull cost center associated with the site. 


DEL[IVERY] AD[DRESS] 
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Table A-3. CUSTOMER Record Fields (cont) 


FLIELD] E[NGINEER] NA[ME] 


Name of the CSD Field Software Support Specialist assigned to the 
site. 


F[IELD] E[NGINEER] TEL[EPHONE] 


Phone number of the CSD Field Software Support Specialist assigned to 
the site. . 


LA[LST] PA[TCHES] 
OP[ERATOR] NA[ME ] 
Name of the site's operator. 


OP[ERATOR] TEL[EPHONE ] 


Phone number of the site's system console. 
RE[PLY] AD[DRESS] 
SITE NA[ME] 
The name of the customer. The contents of this field will “appear in 


the heading of each STAR submitted by the site. 


SYS[TEM] {NO | NUM[BER]} 


The customer's system number, e.g., LX0001. 
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LOGON Area 
The LOGON area contains records that describe valid Logon identifiers. 


Customers may view only their own LOGON record. Table A-4 contains a 
description of the fields in these records. 


Table A-4. LOGON Record Fields 


FIRST {COMM[AND] | CMND} 


A one Line command (up to 80 characters) that is to be executed 
whenever the user Logs on to STARLOG. 


| LA[ST] {OFF | LOGOFF} [TI[ME]] 


Time user last Logged off from STARLOG. 


| LA[ST] {ON | LOG[ON]} [TI[ME]] 


Time user Last Logged on to STARLOG. 


MY ST[UFF] 


User field. 


MY TI[ME] 


Contains the LOGON TIME of the Last session that was terminated 
normally (without using the HOLD option). 


NA[ME] 


Name user wishes to appear in STARS and NOTEs. 
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Table A-4. LOGON Record Fields (cont) 


PRIV[ILEGES] 


User's privileges as determined by the STARLOG administrator. 


PROGRAMMER] pfn 


LADC used field. pfn points to the PROGRAMMER record. 


[SI[GNON]] ACC[OUNT] 


Logon account. 


SI[GNON] NA[ME] 


Logon name. 


[SI[GNON]] PASS[WORD] 


Logon password. 


SITE {NO | NUM[BER]} 


User's site number, e.g., Lx0001. 


TEL[EPHONE ] 


Phone number at which the user may be contacted. 


THIS {ON | LOG[ON]} [TI[ME]] 


Time user logged on for the current session. 
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PRODUCT Area 


The PRODUCT area contains records describing products. Field names within the 
PRODUCT area are Listed in Table A-5. 


Table A-5. PRODUCT Record Fields 


[ MAR[KETING] ] ID[ENTIFICATION] 


Honeywell Bull Marketing identifier. 


NA[ME ] 


Name commonly used in referring to product. 


REL[EASE] VERS[ION] 


Current product version. 


Each PRODUCT record may contain the sub-area VERSION. 


CATEGORY Area 


The CATEGORY area contains records which describe subject names. Fields named 
with the CATEGORY area are Listed in Table A-6. 
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Table A-6. CATEGORY Record Fields 


mm 


PROD[UCT] product-f ield-name 


PROGRAMMER Area 


The PROGRAMMER area contains a record for each person who is recognized as an 
LADC programmer. Only Starlords and LADC programmers may view the contents of 
the programmer area. Fields named within the PROGRAMMER area are Listed in 
Table A-7. . 


Table A-7. PROGRAMMER Record Fields 


EMP[LOYEE { NO | NUM[BER] } 


MAIL SLOT 


Honeywell Bull internal mailing address 


{ MAN[AGER] | MGR } 
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STAR Subjects 


Table A-7. PROGRAMMER Record Fields (cont) 


Table A-8 contains a List of available STARLOG subject categories for which 
STARS may be submitted. 


Before a customer 


is permitted to submit a STAR 
against a particular subject, the customer's site must be Licensed for it. 


Table A-8. STARLOG Subject Categories 


3270 
APL 
BASIC 
CENTRAL 
CONTROL 
DOG 
ELSIE 
FORGE 
GMAP 
HARDWARE 
IMP 
KEYIN 
LOGON 
OPER 
PCL 

PL6 
RCVR2 
SLUG 
SUPER 
TP 
UNITREC 
X29 


CE61-01 


6EDIT 
ARCOM 
BISYNC 
COBOL 
DELTA 
EDIT 
FEP 
FORTRAN 
GMAP6 
HDLCX25 
INIT 
LABEL 
MAIL 
OUTSYM 
PCT 
PLOVER 
REPLAY 
SORT 
SUPPORT 
TPA 

VDH 


ADAPT 
ARES 

C 
COBOLE 
DEMO 
EFT 
FEPLINK 
FPL 
GOOSE 
IBEX 
INSYM 
LEMUR 
MM 
PARTRGE 
PIG 
PRESCAN 
RPG 
SPIDER 
SYSCON 
TPCP 


VARIPORT 


ANLZ 
ARGENT 
CAP 
COBOL85 
DHO3 
ELAN 
FILE 

FPS 
GRAPHICS 


LIBRARY 
NODEADMN 
PACT 
PIGETTE 
QUAC 
SCHED 
STARLOG 
TEXT 
TRADER 
VOLINIT 
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ANVIL 
ASYNC 
CE? 
COMGROUP 
DMIVTP 
ELF 
FIRMWARE 
FROG 

HA? 

IDS 

JAYS 
LINK 
NETCON 
PASCAL 
PIGLET 
RATES 
SHARED_SYSTEM 
STATS 
TOLTS 
TURTLE 

X 


STAR Sever ities 


For each STAR a customer submits, a severity level will be requested. The 
severities may be a numerical value from 1 to 5, D or A. The lower the 
numerical value used for a STAR's severity, the higher the impact of the 
problem on the customer's operation. A severity 1 problem is the most severe 
and should be used only when conditions so indicate. Table A-9 provides 
guidelines for the various severity possibilities. 


Table A-9. STAR Severity Level Guidelines 
Guidelines for Use 


System is down or is crashing so frequently so as to hamper 
productive work. 


Major application won't run. 


Signifies a request by the customer for immediate attention 
from the TAC and/or LADC. 


Customer should follow up with a call to the CP-6 TAC. 


Customer should have available problem documentation or 
testcases to duplicate the difficulty. 


Problem has a serious impact on customer, e.g., can't compile 
a program that's under development. 


Signifies a request by the customer for a patch and/or a 
usable work-around. 


Customer would Like confirmation that a problem does exist. 


Customer should have available problem documentation or 
testcases to duplicate the difficulty. 


Problem moderately impacts the customer. 
A work-around already exists. 


Indicates that the customer would be satisfied with a "fixed 
in the next release" resolution. 


Problem has Little impact. 
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Table A-9. STAR Severity Level Guidelines (cont) 
Guidelines for Use 


5 
D 
A 


Used to report discrepancies between existing documentation 
and current CP-6 behavior. 


Used to report errors in existing documentation. 

Fast response is not critical to the customer. 

Signifies a request for product improvement. 

The fact that a product is working as designed but not as a 
customer would Like is NOT grounds for a severity other than 
Ds 


Used for discussion STARS, i.e., general discussion or 
technical questions. 


Used for reporting problems with programs that reside in the 
X account. 


Used for purposes of tracking (status STAR) critical customer 
events, e.g., BETA testing, installation of new release of 
software. STARs of this nature have been extremely useful in 
providing a highly visible status reporting vehicle for such 
events. 


Analyst Alert STAR 


Used to warn customers about major pitfalls that are 
discovered with either hardware or software. 
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STAR Statuses 


Table A-10 describes the statuses a STAR may assume. 


Table A-10. STAR Statuses 


CLDUP 


Problem resolved as a duplicate of another STAR. 


CLOSED Problem resolved with information supplied. Usually the 
problem was the result of a misinterpretation of existing 


documentation or a user error. 


CLPATCH Problem corrected with the release of a patch. TATTLE 
normally assigns this status to the STAR when a note is added 
indicating the availability of the patch in an incremental 
patch file automatically shipped to customers. 
CLPEND Problem resolved with a fix to source that will be available 


to customers with the next release. 


CLPREL 


Problem resolved by the previous release of the software. 


CLREL Problem resolved by the current release of the software. 


CPANS Problem corrected by a Local patch AND no source updates 
are required. This seldom-used status is used for a STAR 


previously in TPANS status. 
STAR has yet to be reviewed by the Startlord. 
Additional documentation is required for problem analysis to 
proceed. Further work on the problem is normally suspended 


until the receipt of the requested information. 


STAR has been reviewed and, a programmer is assigned to the 
problem. 


Problem has been identified, a patch is available for 
testing, AND there are no source (NS) updates required for 
this STAR. 


Problem has been identified and a patch is available for 


TPATCH 
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Table A-10. STAR Statuses (cont) 


testing. At this point, the patch is not generally available 
to customers until it's been through the patch testing 
procedures at LADC. Customers may request a pre-release of 
the patch through the STAR; however, be aware that it's 

made available on a use-at~your-own-risk basis. 
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Appendix B 


STARLOG Command Summary 


This appendix describes STARLOG command syntax. For information on command 
usage, please refer to Section 7 which discusses the subset of STARLOG 
commands that help CP-6 users to fulfill their support responsibilities. 


Prior to discussing the commands, however, it's necessary to describe a number 
of concepts that are essential in understanding command syntax and usage. 
Invoking STARLOG 
To run the STARLOG processor requires 128K of memory and, for batch runs, the 
STAR pseudo resource. (Use the IBEX command ORES MEM=128 for online sessions 
or RES STAR=1, MEM=128 for batch jobs.) To initiate a STARLOG session after 
Logging on to the LADC support computer simply enter: 

'STARLOG [optionlist ] 


where 


optionlist consists of one option or two options separated by a comma. 
The options are 


NFC for "no first command", causes the first command in the user's 
LOGON record not to be executed. 


LOGON | NA causes the automatic logon information to be skipped. 
Instead, STARLOG prompts for a full logon. This option is primarily for 
use by Starlords. 


STARLOG replies with a greeting, for example: 


STARLOG BO2B 09:45:03 FRI MAR 20 '87 


# 
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Invoking STARLOG 


Positioning and Record Selection 


Before any operation is performed on an existing STARLOG record, it's 
necessary to be positioned to that record. A user accomplishes this by means 
of the FIND or SELECT/STEP commands. Most often the records that customers 
will be positioning to will be STAR, NOTE or LOGON records. In the case of a 
“NOTE record, since it's in a sub-area of the STAR area, it will be necessary 
to first position to the STAR record to which the NOTE belongs and then 
position to the appropriate NOTE. 


STARLOG permits users to identify sets of records by means of the SELECT 
command that allows multiple selection criteria to be specified. The set of 
records thus selected may subsequently be acted upon by either the REPORT 
command to produce a variety of reports or by a "stepping facility" that 
automatically positions to each record in the set to perform some pre-defined 
user task. The WHEN command is used to specify the pre-defined user task. 


Selection Criteria 


STARLOG permits users to position to or locate a record or set of records 
based on some user-specified selection criteria. This criteria is a Logical 
expression made up of the field names, relational and Logical operators, and 
Literals. 


Field Names 


A field is a basic unit of information within a record. Each field has a name 
unique to its area. Fields may be specifically accessed by their names in 
CHANGE, DISPLAY and EDIT commands as well as being used in specification of 
selection criteria in FIND and SELECT commands. Refer ‘to Appendix A for a 
description of the more commonly used field names. 


There are five types of fields, all of which have fixed Length. They are 

1. Decimal 
Consists solely of numeric characters. On display, leading zeroes are 
suppressed. STAR:NUMBER, i.e., the NUMBER field in the STAR area record, 
is an example of a decimal field. 


2. Text 


Consists of any printable characters. On display, trailing blanks are 
suppressed. STAR:TITLE is an example of such a field. 
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Selection Criteria 


3. Multi-line text 


Consists of one or more Lines of printable characters. STAR:DESCRIPTION 
is an example. 


4. Code 


Consists of text fields that are restricted to specific characters. 
NOTE:TYPE is such an example. 


5. Pointer 


Consists of a pointer to another record. The field itself contains no 
displayable data. Its name is used in conjunction with field names within 
the record to which it points. An example of such a field is 

STAR: ORIGINATOR CUSTOMER. It points to the record that describes the 
customer that originated the STAR. Since SITE NAME is a field within the 
CUSTOMER record, a fully qualified pointer field name would be 
STARZORIGINATOR CUSTOMER SITE NAME. 


Logical Operators 
The Logical operators are 


{ NOT | ~ } 

{ AND | & } 

{ OR | I } 
Parentheses, as commonly used in arithmetic expressions, may be used to 
influence the evaluation of terms of logical expressions. The field name or 


relational operator need not be respecified in successive terms if it is the 
same as used in the previous term. For example, 


NUMBER < 5 OR = 7 OR 8 
has the same meaning as 

NUMBER < 5 OR NUMBER = 7 OR NUMBER = 8 
Parentheses may also be used for sub-area criteria by following the Left 
parentheses with a sub-area name and a colon. ALL field names that appear 
within the parentheses must describe fields within the sub-area record. For 
example, 

SUBJECT NAME IS COBOL AND (NOTE:NA IS ‘Jim Smith') 
is a logical expression which is true if a STAR has a SUBJECT NAME of COBOL 
and has any NOTE that was originated by ‘Jim Smith’. 
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Selection Criteria 


Relational Operators 


Relations are used in selection criteria to position to a single record or 
locate a set of records based on the contents of specific fields. The 
relational operators are: 


{ LESS [THAN] | LT | < | BEF[ORE] } 

{ GREAT[ER] [THAN] | GT | > | AFT[ER] } 

{ E[QUAL] [TO] | IS | = } 

{ NOT [EQUAL [TO]] | IS NOT I ~= } 

{ LESS [THAN] [OR] EQU[AL] [TO] | LE | <= } 

{ GREAT[ER] [THAN] [OR] EQU[AL] [TO] | GE ! >= } 
{ CONTAINING | CON[TAINS] | HAV[ING] | WITH } 


NOT { CONTAINING | CON[TAINS] | HAV[ING] | WITH } 


A relation is a field name followed by a relational operator followed by a 
Literal. For example, 


NUMBER = 6600 
or 
TITLE CONTAINS COMP? | CALC? 


Note that the second example above demonstrates that relations may be combined 
with Logical operators to form Logical expressions. ALL comparisons are made 
after translating lower case characters to upper case. This example also 
shows the use of wild-carding; that is, it requests STARS containing the 
strings COMP or CALC in the title. (Wild-carding is permitted only in the 
CONTAINS clause.) 


| . STARLOG COMMANDS 
B-4 CE61-01 


Selection Criteria 


Literals 


Literals may be decimal strings, quoted strings, symbols (unquoted words), 
dates, phone numbers and special names. Two special keyword names are 


ME - depending on the associated field, it refers to the 
user's CUSTOMER: SITE NAME or the user's LOGON: NAME. 


INPUT - is used with the CHANGE command. It instructs 
STARLOG to prompt for the Literal when needed; it is 
used only with multi-line fields. 
The format for dates on input is 
mm[/dd]/yy [hh:mm] 
or 
hhzmm [mm[/dd]/yy ] 
where mm is the month number, dd is the day of the month, yy is the year's 
Last two digits, hh is the hour and mm is the minute of the hour. If only 
hhz:mm is specified, then the date defaults to the current date. 
The format for dates as a Literal in comparisons and modifications is 


mm[/dd]/yy [hh:mm] 


hh:mm [mm[/dd]/yy] 


LAST YEAR - any time during the previous year 
LAST MONTH - any time during the previous month 
{LAST DAY | YEST[ERDAY]} - any time during the previous day 
NOW - current time and date 

WEEK AGO - time 7 days ago 

YEAR AGO - time 365 1/4 days ago 

MONTH AGO - time 30 1/2 days ago 

DAY AGO - time 1 day ago 

TODAY - any time today 


L[AST] {LOGLON] | ON} [TI[ME]] - time of previous session Logon 
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Selection Criteria 


LEAST] {LOGOFF | OFF} [TI[ME]] - time of previous session Logoff 
TLHIS] {LOG/ON | ON} [TI[ME]] - time of current session Logon 


MY TI[ME] - contents of LOGON:MY TIME field (see 
END command) 


The format of a phone number for input or comparison is 


(acd) pre-numb [Xexten] 
or 
HVN pre-numb [Xexten] 


where acd is a three digit area code, pre is a three digit prefix, numb is 
four digit number and exten is an up to five character extension. Use the 
characters "HVN" instead of area code designation for HVN phone numbers. 


Command Concatenation 


STARLOG permits the concatenation of two or more commands into a single entry 
at the command level. The concatenation symbol used to do this is the ".". 
For example, the sequence 


#tcmd1 
#cmd2 
#tcmd3 


is equivalent to 
#comd1.cmd2.cmd3 


where cmd1, cmd2 and cmd3 are valid STARLOG commands. 


Command Variable and Percent Usage 


STARLOG allows command variables to be used in commands and text Lines. A 
command variable is introduced by a percent sign (4). When STARLOG encounters 
a command variable invocation, it substitutes the contents of the command 
variable into the text before parsing it. For example, 


'DATE.X (-15,DATE=TWO_ WEEKS AGO) 

!STARLOG 

#SE STAR ORCU=ME and MODDA > ZTWO_WEEKS AGO.STARSUM 
#END 


reports a STAR summary of all STARS submitted by my site that were modified in 
the Last 15 days. 


STARLOG COMMANDS 
B-6 a CE61-01 


Command Variable and Percent Usage 


Note: Because STARLOG allows command variables to be used, the percent 
character must be entered as ZZ in STARs and NOTEs. 


STARLOG provides a command variable, ZLAST_STAR, containing the number it has 


assigned to the star just built. See Section 7, "Building STAR and Sending 
Testcase in Batch Mode" which illustrates the use of this command variable. 


Commands 


The STARLOG commands can be classified in one of three categories: Record, 
Step, and Miscellaneous commands. 


) Record 
The Record commands give users the ability to enter problem reports 
(STARS), to provide additional information for existing problem reports 
(NOTES), or to modify any data that exists in a STAR or NOTE they've 
previously entered. Record commands include: 
BUILD 
CHANGE 
EDIT 
fe) Step 


The Step commands instruct STARLOG how to "walk through" and extract 
information from the STARBASE. The Step commands include: 


To set very selective criteria for reports/dispLays: 


FIND ALL REST 


~ SELECT FIRST THIS 
WHEN NEXT 


To extract selected information from the STARBASE: 


DISPLAY 
REPORT 


o Miscellaneous 
This set of commands allows users control of I/0 during their STARLOG 


sessions as well as providing an access to CP-6 utilities during their 
sessions. These commands include: 


DATE END LINK MY PAGE 
DIRECTORY ERASE LOGON OFF PRINT 
DO HELP MODE OUTPUT READ 
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Commands 


ALL Command 


Syntax: 
AL[L] [ area: } [ criteria ] 
Parameters: 


area identifies an area within STARBASE. If area: is not specified, then 
the area to which the user is currently positioned is used. 


criteria is a Logical expression composed of field names, relational or 
Logical operators, or Literals that specify which records are to be selected. 
The criteria specified become the current selection criteria. If no criteria 
are specified, then the current selection criteria are used. 


Description: 


The ALL command steps through all of the records in the specified area which 
meet the selection criteria specified. 


The action taken when STARLOG steps to each record is defined by the user via 
the WHEN command. 


Example: 
The commands necessary to obtain a List of all COBOL STARs are 


#WHEN STAR:STARSUM "Instructs STARLOG to produce the STARSUM 
“report whenever the user steps to a STAR 


#ALL STAR:SUNA IS COBOL “Instructs STARLOG to step through to all 
"STARS with a SU/JECT NA/ME of COBOL. 


A more desirable alternative for obtaining the same results is shown as an 
example in the REPORT command section. 
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ALL Command 


BUILD Command 


Syntax: 

BULILD] { STAR |! NOTE } [ FROM fid ]} 

Parameters: 

FROM fid specifies that information for the STAR or NOTE is stored in a 
file. The information in the file must be arranged exactly as if it were 


typed in from a terminal. 


If no FROM fid is specified, STARLOG will prompt for the various fields 
necessary to build either the new STAR record or new NOTE. 


Description: 
The BUILD command is used to create a new STAR or to append a new NOTE to a 
STAR. It's necessary, of course, to first position to a STAR via the FIND or 
SELECT command prior to issuing the BUILD NOTE command. 
Examples: 
1. Building a STAR 

After entering the BUILD STAR command, the following prompts are issued: 

Subject name: A subject category known to STARLOG (see 
Table A-8 for a List) and owned by the 


customer is required here. 


Subject version: The version of the product for which the 
problem is being reported. 


Originator name: The name of the submitter. If a carriage 
return is entered here, the name as stored 
in the user's LOGON record is used. 


Sever ity: The user's perceived severity of the problem 
(see Table A-9 for suggested guidelines). 


Title: The title for the problem report up to 60 
characters. 


After the above data is entered, STARLOG outputs the STAR number as 
follows: 
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BUILD Command 


Star number: nnnnn 
Then, the user is prompted for the description of the problem by 


Description: 


A null response to the successive "-"' prompts terminates the BUILD STAR 
process. 


An example of using the BUILD command online is provided in Section 7. 
2. Building a NOTE 
After entering the BUILD NOTE command, the following prompts are issued: 


Name: . The name of the submitter. If a carriage 
return is input here, the name as stored in 
the user's LOGON record is used. 


Type: For all customer supplied notes, a carriage 
return would suffice. See Table A-2 for a 
List of valid NOTE types. 


At this point, the NOTE's number is output and the user is prompted for 
the text of the NOTE as follows: 


NOTE number: nn 


The NOTE building process is terminated by a carriage return in response 
to one of the successive ‘-"' prompts. 


3. Building STAR in a file 


It may also be convenient to build STAR entries in an edit file, before 
Logging on to the support system. In this case, use a template file of 
the form: 


1.000 subject name 
2.000 subject version 
3.000 

4.000 severity 

5.000 title 
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When building a STAR, use EDIT to merge or copy the template file into the 
beginning of the STAR file. Then re-read (RR) the five Lines. Replace 
the non-blank Lines with correct STARLOG responses. For example, the 
subject could become FORTRAN, subject version could become DOQQ, severity 
could become 3, and title would be whatever is appropriate. Then enter 
the description of the STAR following the title Line. When the STAR 
description is complete, use the command BUILD STAR FROM fid command in 
STARLOG to build the actual STAR. (The originator name is supplied for 
Line 3 when the BUILD STAR command is executed. ) . 


To create a file containing multiple STARs, use a similar template, | 
inserting the STAR description after the title, but instead of using the 
BUILD command, use the READ command. Separate the description of the STAR 
from the following BUILD command by ".END". A file containing two build 
STAR sequences is as follows: 


1.000 BUILD STAR 

2.000 subject name 

3.000 subject version 

4.000 

5.000 severity 

6.000 title 

7.000 description (may be multiple Lines) 
8.000 .END 

9.000 BUILD STAR 
10.000 subject name 
11.000 subject version 

12.000 

13.000 severity 
14.000 title 
15.000 description (may be multiple Lines) 


16.000 -END 
Using this file as a template, the first of two STARS could appear as 
follows: 
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1.000 BUILD STAR 
2.000 CENTRAL 
3.000 C01 


5.000 2 

6.000 <XYZ> UDE-501-7 @ KQTSTREES+.2222 

7.000 The screech occurred during a ZAP of the system. After recovery 
7.100 another ZAP proceeded without incident. Preliminary analysis 
7.200 information will be beamed to .ZZZTEST. The dump @XYZ will 
7.300 be star_AQ05.:SYSTAC2. We're running on week 702 patches. 

8.000 .~END 


CHANGE Command 


Syntax: 

CHLANGE] [ area: ] fldn {{ TO | = } € Literal | INPUT } | FROM fid } 
Parameters: 

area identifies an area within STARBASE. If area: is not specified, then 


the area to which the user is currently positioned is used. 
fldn represents a field name which exists in the area being modified. 


Literal represents a valid Literal as described previously in this section 
that matches the data type of the field being modified. 


INPUT specifies multi-Line text fields. STARLOG will prompt the user for 
successive Lines of input. 


fid specifies a file containing the replacement field (i.e., the Literal or 
INPUT). The special symbol ".END" signals the end of multi-line text input. 


Description: 


The CHANGE command is used to alter the contents of specific fields of the 
current record. The EDIT command is recommended for altering STAR 
descriptions or NOTE text. 
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Example: 
Change the subject name of an existing STAR, 1234, to FORTRAN. 


#1234 "FIND command to position to STAR 1234 
#CH SUNA TO FORTRAN “Changes SUBJECT NAME to FORTRAN 


Other examples are in Section 7. 


DATE Command 


Syntax: 
{ DATE | TIME } 
Description: 


DATE (and its synonym TIME) displays the current date and time. The format of 
the display is: 


mmm dd ‘yy hh:mm (month) (day) (year) (hours) (minutes) 

Examples: 

#ADATE 

requests a display of the current date and time. A sample display is: 


MAR 02 ‘86 11:03 


DIRECTORY Command 


Syntax: 
{ DIR[ECTORY] } [ fid | R[ESET ]] 
Parameters: 


fid specifies the new default account fid, and may consist of an account or 
a packset name and an account. 


RESET specifies that the default account is to be reset to the running 
account. 
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Description: 

This command changes the default account and packset. The default account and 
set are the account and associated packset that are selected if an account is 
not supplied as part of a disk file fid specification. Initially, the default 
account is the Logon or running account and the packset name is nil. When 
used without parameters, DIRECTORY displays the current directory pointer. 
Examples: 

#DIRECTORY .ZZZCUST 

This command directs that subsequent fids that do not include an account are 
to default to the .ZZZCUST account and the packset associated with that 
account. 


#DIRECTORY RESET 


This command re-establishes the running account and its associated packset as 
the default. 


DISPLAY Command 


Syntax: 
_DI[SPLAY] [ area: ] { displaylist | ALL } [ step ] [ criteria ] 
Parameters: 


area identifies an area within STARBASE. If area: is not specified, then 
the area to which the user is currently positioned is used. 


displaylist | ALL specifies one or more fields in either a STAR or NOTE to 
be displayed. The items in the displaylist are identified by field name and 
are separated by commas. If ALL is specified, all major fields are displayed. 


step specifies which records are to be stepped to for the desired report. 
Valid step specifications are 


FIRST - step to the first record satisfying the selection 
criteria. 

NEXT - step to next record satisfying the selection criteria. 

REST - steps through all the records satisfying the selection 


criteria starting after the record to which the user 
is currently positioned. 
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ALL - steps through all the records satisfying the selection 
criteria. This is the default, if step is not 
specified. 


criteria is a logical expression composed of field names, relational or 
Logical operators, or Literals that specify which records are to be selected. 
The criteria specified become the current selection criteria. If no criteria 
are specified, then the current selection criteria are used. 


Description: 


The DISPLAY command is entered following the SELECT or FIND command to 
generate displays of specified fields of selected STARS/NOTEs. If a step 
command is specified, the DISPLAY command becomes the new default WHEN 
command. The DISPLAY command applies only to the immediately preceding FIND 
or SELECT command. A global DISPLAY command is enabled through the WHEN 
command. 


Examples: 


1. To display just the STAR number field of STAR 8821 and the NOTE types 
attached to it, the STARLOG user enters: 


#FIND STAR: NUMBER=882 1 
#DISPLAY NUMBER, (NOTE:TYPE) 


2. To display all STARs whose subject name is FEP, the STARLOG user enters: 


#SELECT STAR: SUBJECT NAME IS FEP 
#DISPLAY ALL 


3. To display the number, title and status of a STAR, the STARLOG user 
enters: 


#FIND STAR: NUMBER=8821 
#DISPLAY NUM, TITLE, STATUS 


DO Command 
Syntax: 
{ DO | ! } IBEX-command 
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Parameters: 


IBEX-command any Legal IBEX command. See the CP-6 Programmer Reference 
Manual (CE40Q). 


Description: 


The DO command allows the user to execute an IBEX command without exiting the 
current processor. 


Note: The ! (exclamation point) may be used instead of the word DO. It 
should be noted however that if the ! is used in an XEQ file, it will 
terminate the current processor session unless preceded by at Least one blank, 
or entered as a double ! (!!). 
Examples: 
1. To display the current system status enter 

#D0 DI 


2. To set up a title and page number for a report destination enter 


#'LDEV LPO9 TITLE='report title’ ,PAGE=100,COPIES=3 


EDIT Command 


Syntax: 
ED[IT] [ area: ] fldn 
Parameters: 


area identifies an area within STARBASE. If area: is not specified, then 
the area to which the user is currently positioned is used. 


fldn represents a field name which exists in the area being modified. 


Description: 


The EDIT command works in one of two ways depending on the type of field being 
edited. If the field is not a multi-line text field, then the field is output 
to the user's terminal with the cursor left at the end of the field. The user 
at that point is free to use the standard CP-6 backspace editing commands to 
correct the data as desired. 
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If the field to be modified is a multi-line text field, then the data is 
written to a temporary file, *STAREDIT, and the CP-6 editor, EDIT, is given 
control with the file open for modification. 
ExampLes: 
1. To edit the body of a STAR, enter: 
starnumber .ED DESC 

which positions to the specified star number at the description 

portion and prompts for entry of edit commands. *STAREDIT is the 

temporary file that contains the STAR description. 
2. To edit the title of a STAR, enter: 


starnumber.ED TITLE 


which displays the title and positions the cursor at the end of the 
title Line. You may then delete and retype characters as needed. 


3. To edit a NOTE, enter: 
starnumber .:notenumber .ED TEXT 
which positions to the specified star number at the specified note 


number and prompts for entry of edit commands. *xSTAREDIT is the 
temporary file that contains the NOTE text. 


END Command 


Syntax: 
{ EN[D] | X | Q{UIT] } [ HO[LD] ] 
Parameters: — 


HOLD causes the field MY TIME in the user's LOGON record not to be updated 
when the session is terminated. Normally, MY TIME is updated to be the same 
date and time as the field LAST LOGON TIME in the LOGON record. The HOLD 
option is convenient when the LAST LOGON TIME needs to be preserved for use in 
a Later session. 
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Description: 


The END command is used to exit STARLOG and return to the IBEX Level. 


ERASE Command 


Syntax: 
ERASE [ ALL | ldevlist ]} 
Parameters: 


ALL specifies that the accumulated output for all logical devices is to be 
deleted. This is the default. 


Ldevlist specifies that the accumulated output for the specified Logical 
device or devices is to be deleted. The List is entered in the format 


Ldevname[ ,Ldevname]... 

Ldevname is a logical device name established through the LDEV command. 
Description: 

ERASE deletes the accumulated output for Logical devices. 

Examples: 

#ERASE ALL 


deletes all output accumulated for all Logical devices defined for the session 
or job. 


FIND Command 


Syntax: 
FILND] [ step ] [ areas ] criteria (Format 1) 
-or - 
{ ni [:n2] | :n3 } (Format 2) 
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Parameters: 


step represents either FIR/ST or NE/XT. If neither is specified, NEXT is 
assumed. 


area identifies an area within STARBASE. If area: is not specified, the 
area to which the user is currently positioned is used. 


criteria is a Logical expression composed of field names, relational or 
Logical operators, or Literals that specify which records are to be selected. 
The criteria specified become the current selection criteria. If no criteria 
are specified, then the current selection criteria are used. 

n1 is a STAR number. 

n2 is a NOTE number. 

n3 is a NOTE number within the current STAR. 

Description: 

The FIND command positions to the first or next occurrence of a record fitting 
the specified criteria independent of the current selection criteria defined 


by the SELECT command. 


The second form of the FIND command, probably the more useful of the two, is 
used to position to STARS or NOTEs. 


Note: If the response to a FIND command for a specific STAR is the message 
"xxk Nothing found", that STAR is probably closed and archived. To view such 
STARS, invoke the processor ARCHLOG.STAR which accepts STARLOG commands. 


Examples: 


The following pairs of command sequences are identical: 


Format 1 Format 2 Description 
#FIND STAR: NUMBER=1234 #1234 Positions to STAR 1234 
#FIND STAR: NUMBER=1234 #1234:5 Positions to NOTE 5 of STAR 1234 


#FIND NOTE: NUMBER=5 

#FIND NOTE: NUMBER=10 #:10 Positions to NOTE 10 of the 
STAR to which the user is 
currently positioned 


Additional usage examples may be found in Section 7. 
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FIRST Command 

Syntax: 

FIR[ST] [ area: ] [ criteria ] 
Parameters: 


area identifies an area within STARBASE. If area: is not specified, then 
the area to which the user is currently positioned is used. 


criteria is a logical expression composed of field names, relational or 
Logical operators, or Literals that specify which records are to be selected. 
The criteria specified become the current selection criteria. If no criteria 
are specified, then the current selection criteria are used. 


Description: 


The FIRST command causes a sequential search for the first record in the area 
which meets the specified selection criteria. 


The action taken when STARLOG steps to each record is defined by the user via 
the WHEN command. : 


Example: 


The commands necessary to produce a STAR report for the first STAR submitted 
by the user are 


#WHEN STAR:STAR “Instructs STARLOG to produce the STAR 
“report whenever the user steps to a STAR. 


#FIRST STAR:ZORNA IS ME “Instructs STARLOG to step through to the 


"first STAR with a OR/IGINATOR NA/ME of ME 
"Ci.e., the name specified in LOGON: NAME). 
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HELP Command 


Syntax: 
HLELP] [ (fid) ] [ TOPICS ] [ keyword’ [ - ] [ keyword2 ] ] 


Note: The following elements can be specified in any order: 
(fid) 
TOPICS 
[ keyword? ] [ - ] [ keyword2 ] ] 


For example, HELP (fid) keyword] - keyword2 TOPICS is acceptable. 
Parameters: 


(fid) specifies the processor name (for example, STARLOG). If (fid) is 
omitted, the current processor iS assumed. The processor name can be ? to 
request a Listing of processors that have HELP facilities available. 


TOPICS requests a List of topic or subtopic names, rather than an 
information message. 


keyword! [-] [keyword2] specifies a topic, a range of topics, or a topic 
and subtopic to identify what HELP information is requested. keyword’ and 
keyword2 may be abbreviated (by truncation). 


FORM RESULT 


HELP (fid) TOPICS Lists all topics 
HELP (fid) TOPICS keyword1 - keyword2 Lists all topics in the range 
specified by keyword? - keyword 2 — 


HELP (fid) TOPICS keyword1? Lists all topics beginning with 
the prefix specified by keyword’ 
HELP (fid) TOPICS keyword1 Lists all subtopics for the 


topic specified by keyword’ 


HELP (fid) keyword1 Displays the first Level 
information message for 

| the topic keyword’ 

HELP (fid) keyword? keyword2 Displays the information 
message for keyword1, but only 
the level identified by the 
subtopic keyword2 


keyword? may include the wild-card (?) character as the rightmost character, 
if TOPICS is specified. 
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Description: 

HELP displays information. 

HELP messages have levels. Once the initial level has been displayed, 
entering a question mark displays the next level, usually containing greater 
detail. Entering two question marks displays the entire message. 

Examples: 


HELP (STARLOG) BUILD 


displays the syntax of the BUILD command. Entering ?? displays additional 
information on the BUILD command. 


HELP (STARLOG) SUBJECT 

displays the available STAR subjects. 

HELP (STARLOG) SEVERITY 

displays the meaning of STAR severity codes. 
HELP (STARLOG) ASTAR TOPICS 


displays all fields within the STAR area. 


LINK Command 


Syntax: 

LINK fid 

Parameters: 

f id specifies the CP-6 processor to which control is to be transferred 
Description: 

The LINK command causes an M$LINK to be issued to the processor specified by 


fid. When the processor receiving control is terminated, control returns to 
STARLOG. 
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LOGON Command 


Syntax: 
LO[GON] [ HO[LD] ] 
Parameters: 
HOLD specifies that the value stored in MY TIME, a STARLOG user-profile 
parameter that contains the Logon time for the previous STARLOG session, not 
be updated. 
Description: 
The LOGON command ends the current STARLOG session and permits the user to 
Logon to STARLOG with a different account name. Specifying HOLD notifies 
STARLOG not to change the value of the MY TIME parameter. HOLD is specified. 
when the STARLOG user wishes to treat multiple STARLOG sessions as continuous | 
sessions, usually for tracking purposes. 
Examples: 
To Logon with a different account name, the STARLOG user enters: 

#LOGON 


The system responds: 


STARLOG BO2B 15:05:18 WED JUN 10 '87 
Please Log on: 


The user may respond with: 
1. account,name,password [ (option) ] 
2. account,name [ (option) ] 
3. password [ (option) ] 
4. [ (option) ] 


For responses 3 and 4, the account, name are taken from the JIT. The Logon 
option permitted is NFC, meaning don't execute the FIRST COMMAND. 
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MODE Command 


Syntax: 
MODE [ BE[GINNER] | EX[PERT] ]} 
Parameters: 


BEGINNER directs STARLOG to prompt with STAR> or NOTE> depending 
current default location (set by a FIND or SELECT command). 


EXPERT directs STARLOG to prompt with #4, the default. 
Description: 


The MODE command allows the user to change the STARLOG prompt mode. 


on the 


If the 


MODE command is issued and neither BEGINNER or EXPERT are specified, STARLOG 


will display the current mode. 
Examples: 
To request prompting in Beginner's mode, the STARLOG user enters: 


#MODE BEGINNER 
STAR> 


To position to a NOTE, STARLOG prompts as follows in Beginner mode: 
STAR>FIND STAR: NUMBER=1234 


STAR>FIND NOTE: NUMBER=1 
NOTE>REPORT NOTE 


MY Command 

Syntax: 

MY fldn { = | IS } Literal [ , fldn { = | IS } Literal ] ... 
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Parameters: 
fldn represents a field name which exists in the area being modified. 


Literal represents a valid Literal as described previously in this section 
that matches the data type of the field being modified. 


Description: 
The MY command is used to change the user's image as viewed by STARLOG. The 
user may change NAME, SITE, etc. in order to create STARS and NOTES as the 


proper entity. This facility is primarily to be used by support personnel 
when reporting problems experienced by their customers. 


NEXT Command 

Syntax: 

{ NE[XT] | > } [ area: ] [ criteria ] 
Parameters: 


area identifies an area within STARBASE. If area: is not specified, then 
the area to which the user is currently positioned is used. 


criteria is a logical expression composed of field names, relational or 
Logical operators, or Literals that specify which records are to be selected. 
The criteria specified become the current selection criteria. If no criteria 
are specified, then the current selection criteria are used. 


Description: 


The NEXT command causes a sequential search starting from the current position 
in the area for the first record which meets the specified selection criteria. 


The action taken when STARLOG steps to each record is defined by the user via 
the WHEN command. 


Example: 


The commands necessary to produce a STAR report for the all the STARS 
submitted by the user in step mode are 


#WHEN STAR:STAR “Instructs STARLOG to produce the STAR 
“report whenever the user steps to a STAR 
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#FIRST STAR:ORNA IS ME “Instructs STARLOG to step through to the 
“first STAR with a OR/IGINATOR NA/ME of ME 
"(Ci.e., the name specified in LOGON: NAME) 

#NEXT “Instructs STARLOG to step to the next STAR 
“that meets the current selection criteria 


"of ORNA IS ME. This action is performed 
“each subsequent NEXT that is entered. 


OFF Command 


Syntax: 

{ OFF | BYE } [ HO[LD] ] 

Parameters: 

HOLD specifies that the value stored in MY TIME, a STARLOG user-profile 
parameter that contains the Logon time for the previous STARLOG session, not 
be updated. 

Description: 

The OFF command is used to exit STARLOG and terminate the current CP-6 
session. Specifying HOLD notifies STARLOG to not change the value of the MY 
TIME parameter. HOLD is specified when the STARLOG user wishes to treat 
multiple STARLOG sessions as continuous sessions, usually for tracking © 
purposes. 

Examples: 


To exit STARLOG and log off the CP-6 system, the STARLOG user enters: 


HOFF 
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OUTPUT Command 
Syntax: 


[[ ON ] LP[@lLocation ]] 
OU[TPUT] [[ OVER ] fid 7] 
[{ INTO ] ME 7] 
[[ To ] ] 


Parameters: 


{ONITOIOVERI INTO} directs file output processing. 
file to be overwritten. INTO causes file extension. 
used to create a new file. If the file exists, 

an error will occur. The default is ON. 


fid any valid CP-6 file identifier. 


OVER causes an existing 
ON and TO are synonyms 


LP directs output to the default Line printer. @location identifies a 


specific Line printer. 
ME redirects output to the user's terminal. 


Description: 


This command sends subsequent output to the specified destination. 


Examples: 


#HOUTPUT ON OUTPUTFILE 
#OUTPUT ON ME 


PAGE Command 


Syntax: 


PA[GE] 
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Description: 
The PAGE command causes a page eject to occur. 
Examples: 


To specify page ejects between STAR reports, the STARLOG user enters, for 
example: 


#SELECT STAR: (SUBJECT NAME IS FEP) AND (NOTE:DATE > 04/08/87) 
#REPORT STARSUM 
#PAGE 


#SELECT STAR: (SUBJECT NAME IS VDH) AND (NOTE: DATE > 04/08/87) 
#REPORT STARSUM 


PRINT Command 

Syntax: 

PRINT [ ALL | tdevlist J 
Parameters: 


ALL specifies that the accumulated outputs for all Logical devices are to 
be sent to their destinations immediately. This is the default. 


Ldevlist specifies that the accumulated outputs for the specified Logical 
device or devices are to be sent to their destination(s) immediately. The 
List is entered in the format 

Ldevname[ ,ldevname]... 

ldevname is a logical device name established through the LDEV command. 


Description: 


PRINT directs that output accumulated for logical devices be sent to its 
destination immediately. , 


Examples: 
#PRINT LPO1,LPO02 


The above example causes the accumulated output associated with Logical 
devices LPO1 and LPO2 to be sent immediately to the associated destinations. 
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READ Command 
Syntax: 

REA[D] fid 
Parameters: 


fid is a file containing commands exactly as would be entered at a terminal 
during an interactive STARLOG session. 


Description: 


The READ command reads and executes commands stored in a file. As each 
command is executed, it is echoed. 
REPORT Command 


Syntax: 


[ RE[PORT] ] rptname [ step ] [ criteria ] 


Parameters: 
rptname represents the name of the desired report. Possible report names 
are 

STARSUM ~- one Line description of a STAR 

NOTE ~ a formatted display of a NOTE record 

STARNOTE - a STARSUM report for a STAR followed by NOTE reports 

for each NOTE associated with the STAR 
STARONLY - a formatted display of a STAR 
STAR - a STARONLY report for a STAR followed by NOTE reports 


for each NOTE associated with the STAR 
STARPAGE - STAR report preceded by a page eject 


step specifies which records are to be stepped to for the desired report. 
Valid step specifications are 
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FIRST - step to the first record satisfying the selection 


criteria. 
NEXT - step to next record satisfying the selection criteria. 
REST - steps through all the records satisfying the selection 


criteria starting after the record to which the user 
is currently positioned. 


ALL - steps through all the records satisfying the selection 
criteria. This is the default, if step is not 
specified. 
criteria is a logical expression composed of field names, relational or 


Logical operators, or Literals that specify which records are to be selected. 
The criteria specified become the current selection criteria. If no criteria 
are specified, then the current selection criteria are used. 

Description: 


The REPORT command generates formatted displays of STARS and NOTEs. It is the 
primary vehicle by which customers extract information from the STARBASE. 


Examples: 

1. To List all the COBOL STARs, enter 
#STARSUM ALL SUNA IS COBOL 

2. To display your site's STARs for which there has been activity since your 
last logon, enter the following command. The field MY TIME is usually 
used instead of LAST LOGON TIME (see the description of the END command's 
HOLD option). 
#STAR ALL ORCU SITE NA IS ME & MOD DA >= MYTI 
The above command instructs STARLOG to step to all STARS whose ORIGINATOR 
CUSTOMER SITE NAME is ME (i.e., that which is stored in the user's 


CUSTOMER record) AND whose MOD/IFICATION DA/TE is greater than or equal to 
the user's LOGON:MY TI/ME and to produce the STAR report for each. 
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REST Command 


Syntax: 
RES[T] [ area: ] [ criteria ] 
Parameters: 


area identifies an area within STARBASE. If area: is not specified, then 
the area to which the user is currently positioned is used. 


criteria is a Logical expression composed of field names, relational or 
Logical operators, or Literals that specify which records are to be selected. 
The criteria specified become the current selection criteria. If no criteria 
are specified, then the current selection criteria are used. 


Description: 


The REST command steps through all of the records, starting after the one to 
which the user is currently positioned, which meet the selection criteria 
specified. 


The action taken when STARLOG steps to each record is defined by the user via 
the WHEN command. 


Example: 


The commands necessary to List all FORTRAN STARs that were submitted that have 
a number greater than 30000 and have either the word ENCODE or DECODE in the 
title are 


#30000-STARSUM REST SUNA IS FORTRAN & (TI CONTAINS ENCODE | DECODE) 


The first command above, a form of the FIND command, positions the user to 
STAR #30000. The second steps through all the STARs after 30000 that meet the 
specified criteria and produces the STARSUM report for each. 


Note that this is a frequently used feature since, if a user knows 
approximately where a STAR that's being searched for exists, then it's 
desirable to begin the search well into the STARBASE rather than wasting time 
searching unnecessary STARs. 
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SELECT Command 


Syntax: 
SE[LECT] [ area: ] [ criteria ! ALL ]} 
Parameters: 


area identifies an area within STARBASE. If area: is not specified, then 
the area to which the user is currently positioned is used. 


criteria is a logical expression composed of field names, relational or 
Logical operators, or Literals that specify which records are to be selected. 
The criteria specified become the current selection criteria. If no criteria 
are specified, then the current selection criteria are used. 

ALL specifies that all the records are selected. 

Description: 

The SELECT command identifies a particular set of records within the specified 
area. The command simply establishes the selection criteria which will be 
used by the user stepping through the STARBASE. It does not position itself 
position to any record. Positioning is accomplished by means of a step or 
FIND command. 

If a SELECT command is in effect for an area of the STARBASE and you issue 
another SELECT command for the same area, the new selection criteria replace 
the previous selection criteria. 

Example: 


See example 2 for the WHEN command for a SELECT usage example. 


THIS Command 


Syntax: 


{ THLIS] | * } [ STARINOTE 7] 
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Parameters: 

STAR changes the Location to STAR. 

NOTE changes the Location to NOTE. 

Description: 

The THIS command "resteps" to the current position Letting the user see the 
previous position again. The THIS command is primarily useful if a WHEN 
command has been specified. The THIS command can be used to help locate the 
current processing position by "revisiting” the Last executed WHEN REPORT or 
WHEN DISPLAY command. 


Examples: 


To display a STAR again which has just been stepped to, the STARLOG user 
enters: 


#WHEN STAR: REPORT STAR 


#SELECT STAR: ORIGINATING CUSTOMER NAME IS ME 
#FIRST 


WHEN Command 


Syntax: 


WHLEN] [ operation }] [ area: ] [ command ] 


Parameters: 
operation is one of the following: 
FIND - indicates that the command specified is to be performed when 


a successful FIND is executed 


SELECT - indicates that the command specified is to be performed when 
a successful SELECT is executed 
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WHEN Command 


STEP - indicates that the command specified is to be performed for 
each record the user steps. This is the default, if 
operation is not specified. 


area identifies an area within STARBASE. If area: is indicated, then 
either STAR: or NOTE: must be specified. It indicates the type of record the 
user is to position via a FIND, SELECT or step operation. 


If no area: is specified, then the area of the record to which the user is 
currently positioned is used. To avoid confusion, it's recommended that this 
specification always be made. 


command must be a REPORT command (e.g., STARSUM) or a DISPLAY command. If 
no command is specified, the indicated WHEN is reset. 


Description: 


The WHEN command is used to define a REPORT command to be automatically 
executed whenever a STEP, FIND and/or SELECT command is successfully 
per formed. 


If a WHEN command is in effect for an area of the STARBASE and you issue 
another WHEN command for the same area, the new WHEN command replaces the 
previous WHEN command. 


Examples: 


1. The commands necessary to output a STARSUM report whenever a STAR is 
positioned to via a FIND or STEP operation are 


#WH STAR: STARSUM "Instructs STARLOG to perform a STARSUM report 
“whenever the user steps to a STAR. 


#WH FI STAR:STARSUM "Instructs STARLOG to perform a STARSUM report 
“whenever the user positions to a STAR via the 
“FIND command. 


In this case, a STARSUM report would be produced for the first two 
commands that follow but not the third: 


#1234 "FIND STAR number 1234 
#NEXT "STEP to the NEXT STAR following 1234 
#SE STAR: NUM=1234 "SELECT STAR number : 1234 
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WHEN Command 


2. The following shows the commands necessary to step unconditionally through 
all the STARS submitted by the user's site with a number > 20000, 
producing a STARONLY report (STAR description with no NOTES) for each. In 
addition, commands are shown that permit the user, after positioning to 
each STAR, to display only those NOTEs that have been added/modified since 
the user Last logged on. 


#WH STAR: STARONLY "Instructs STARLOG to produce a STARONLY 
"report each time the user steps to STAR. 


#SE STAR: ORCU SITE NA IS ME "Sets the selection criteria for the STAR 
“area to ORIGINATOR CUSTOMER SITE NAME 
“equal ME (i.e., all STARS submitted with 
"an ORCU SITE NA equal to that stored in 
“the user's CUSTOMER record). 


#SE NOTE:DA >= MYTI "Sets the selection criteria for the NOTE 
“area to DATE greater than or equal to 
“MY TIME (see the HOLD option of the END 


“command). 
#20000.NEXT STAR.NOTE "Three commands are used here: 
" 20000 - positions (FIND) to the STAR 


= with number = 20000. 

" NEXT STAR - starting from STAR 20000, 
search forward for a STAR 
meeting the current selection 
criteria for the STAR area. 
Note if one is found, a 

- STARONLY report is produced. 
" NOTE - produces a NOTE report for 

" each NOTE that meets the 
current selection criteria 

" for the NOTE area. 


"After the appropriate displays are output, 
"it is possible for the user to append 
"information to the currently positioned 
“STAR without impacting the STAR and NOTE 
"current selection criteria. 


#NEXT STAR.NOTE "To repeat the process for the next STAR. 
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Appendix C 


CP-6 Support Telephone Numbers 


This appendix Lists the telephone numbers used in the CP-6 support process. 
Refer to the appropriate section Listed below for additional information. 


National Response Center (NRC) 


In Georgia (800) 282-4350 
In any state other than Georgia (800) 241-1634 


See Section 3 in this Handbook for the NRC call procedure. 


Support Computer (ASYNC) 


(300 baud) 


(1200 baud) 


Please consult your Honeywell Bull Marketing 
Representative for these telephone numbers. 


See Section 5 on aSynchronous access to the support computer. 


Support Computer (SYNC) (2400 baud) 
In California 
In any state other than California 


Please consult your Honeywell Bull Marketing 
Representative for these telephone numbers. 


See Section 5 on synchronous access to the support computer. 
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TYMNET Customer Support (800) 336-0149 


TYMNET Local Number/Logon / 


For the Local TYMNET number, call TYMNET Customer Support, Listed 
above. 


For the TYMNET Logon string, consult your Honeywell Bull Marketing 
Representative. 


See Section 5 for the TYMNET access procedure. 
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